Currently X with most Window managers calls 'exit' when the close button
is used. This can cause issues as the Window is not properly destroyed.
With this change we can handle this window message and properly exit.
R=reed@google.com
Author: bungeman@google.com
Review URL: https://codereview.chromium.org/377733002
This is a first piece of the GPU YUV decoder, which is the actual effect that performs the conversion. For now, it simply applies the conversion matrix, since it is all I need. I may add modes if different matrices need to be applied or if I add color profile support here.
I'll try to keep these cls short and easy to review, but there should be a few of them coming once this one is in.
BUG=skia:
R=senorblanco@chromium.org, senorblanco@google.com, reed@google.com, bsalomon@google.com
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/378503006
This splits the playback functionality out of SkPictureData. The old SkPictureData::draw method is pulled out along
with its supporting functions as verbatim as possible. Some follow on CLs will be required to:
re-enable profiling in the debugger (and remove the vestiges of SkTimedPicture)
re-enable display of command offsets in the picture (this should probably wait until we've switched to SkRecord though)
Clean up CachedOperationList (maybe fuse with SkPicture::OperationList)
Split SkPicturePlayback into a base class and two derived classes
Implement parallel version of GatherGPUInfo for SkRecord
Landing this is blocked on removing Android's use of the abortPlayback entry point.
R=mtklein@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/377623002
We're racing to invalidate the genID of our pixel ref when multiple
threads write into it, and also to call its genID-changed listeners.
We install no listeners on this particular pixel ref, nor do we ever
care about its genID at all. So these are benign races, races on
data we never make a decision from.
BUG=skia:2725
R=jcgregorio@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/370353004
Now that we're drawing tiles threaded like implside painting, remove the checks
that those lock counts are balanced. They're just not right for anyone anymore.
SkBitmaps themselves are not threadsafe (even const ones), so shallow copy them
on playback of an SkRecord. (The underlying SkPixelRefs are threadsafe.)
Simplify quilt drawing by using SkBitmap::extractSubset. No need for locking.
Bump up to 256x256 tiles. 16x16 tiles just murders performance (way too much
contention). This has the nice side effect of letting us enable a bunch more
GMs for quilt mode; they drew wrong with small tiles but exactly right with large.
BUG=171776
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/371023005
Add OpenGL ES extension functions needed to support NV_path_rendering in OpenGL
ES.
The added glProgramPathFragmentInputGenNV call is defined in NV_path_rendering
revision 30, similar to following:
Append to the end of the "Shader Inputs" subsection of Section 3.12.2
"Shader Execution":
The command
void ProgramPathFragmentInputGenNV(uint program,
int location,
enum genMode,
int components,
const float *coeffs);
controls how a user-defined (non-built-in) fragment input of a
GLSL program object is computed for fragment shading operations that
occur as a result of CoverFillPathNV or CoverStrokePathNV.
/program/ names a GLSL program object. If /program/ has not been
successfully linked, the error INVALID_OPERATION is generated.
The given fragment input generation state is loaded into the fragment
input variable location identified by /location/. This location
is a value returned either by GetProgramResourceLocation with a
/programInterface/ of FRAGMENT_INPUT_NV and a given fragment shader
input variable name or by GetProgramResourceiv with FRAGMENT_INPUT_NV
for the /programInterface/ and LOCATION for the property for a given
fragment input resource index.
....
glProgramPathFragmentInputGenNV will be used instead of glPathTexGen,
because the latter depends on fixed function pipeline that is not
exposed in ES.
Also add glGetProgramResourceLocation from OpenGL 4.3 or
ARB_program_interface_query.
Also add FRAGMENT_INPUT define to be used with glGetProgramResourceLocation.
The added functions are not used yet, but they're needed when implementing
NV_path_rendering support for OpenGL ES. They can also be used on OpenGL.
Remove uncalled NV_path_rendering functions, so they do not cause confusion
or take space in the interface definition. The ones that are later used
can be re-added when needed.
Remove definitions NV_path_rendering that are for NV_path_rendering function
parameters that are not used. The ones that are later used
can be re-added when needed.
Committed: https://skia.googlesource.com/skia/+/4a995dfff2ecf91e8bf999d77e3218cec596232cR=bsalomon@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/345723002
If there is no pixelRef, do not attempt to dereference it.
This was caught running on Android, where we don't have the resources
folder (tracked in b/14406768). We fail to decode anything, and then
attempt to encode an SkBitmap without a pixelRef.
R=krajcevski@google.com
Author: scroggo@google.com
Review URL: https://codereview.chromium.org/362413005
