This adds an invalidation listener mechanism to SkPixelRef to let it send this message while still staying ignorant of who's listening.
These messages are tricky to deliver. The SkPixelRefs they originates from and the GrResourceCaches they ultimately end up at may be on different threads; neither class is threadsafe; their object lifetimes are totally independent; it's a many-senders-to-many-receivers relation; and neither codebase should really know about the other.
So I've added a per-message-type global message bus to broadcast messages to threadsafe inboxes. Anyone can post() a message, which will show up in all the inboxes of that type, read whenever the inbox's owner calls poll(). The implementation is _dumb_; it can be improved in several dimensions (inbox size limits, lock-free message delivery) if we find the need.
I took some care to make sure not to send the invalidation message for any SkPixelRef that's sharing a generation ID with another SkPixelRef.
BUG=
R=bsalomon@google.com, scroggo@google.com, reed@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/26734003
git-svn-id: http://skia.googlecode.com/svn/trunk@11949 2bbb7eff-a529-9590-31e7-b0007b416f81
This returns true if (1) the picture has finished recording and
(2) this picture or any picture drawn into it refers to any bitmaps.
It allows clients doing complicated manipulations of the picture to
early-out when there are no bitmaps present.
BUG=303281
R=reed@google.com
git-svn-id: http://skia.googlecode.com/svn/trunk@11935 2bbb7eff-a529-9590-31e7-b0007b416f81
Adds GrEffect::willUseInputColor() which indicates whether or not the
input color affects the output of the effect. This is needed for
certain Xfermodes, such as kSrc_Mode. For these modes the color filter
will not use the input color.
An effect with GrEffect::willUseInputColor() true will cause all color
or coverage effects before it to be discarded, as their computations
cannot affect the output. In these cases program is marked as having
white input color.
This fixes an assert when Skia is compiled in a mode that prefers
using uniforms instead of attributes for constants. (Flags
GR_GL_USE_NV_PATH_RENDERING or GR_GL_NO_CONSTANT_ATTRIBUTES). Using
attributes hides the problem where the fragment shader does not need
input color for color filters that ignore DST part of the filter. The
assert would be hit when uniform manager tries to bind an uniform which
has been optimized away by the shader compiler.
Adds specific GrGLSLExpr4 and GrGLSLExpr1 classes. This way the GLSL
expressions like "(v - src.a)" can remain somewhat readable in form of
"(v - src.a())". The GrGLSLExpr<typename> template implements the
generic functionality, GrGLSLExprX is the specialization that exposes
the type-safe interface to this functionality.
Also adds operators so that GLSL binary operators of the form
"(float * vecX)" can be expressed in C++. Before only the equivalent
"(vecX * float)" was possible. This reverts the common blending
calculations to more conventional order, such as "(1-a) * c" instead of
"c * (1-a)".
Changes GrGLSLExpr1::OnesStr from 1 to 1.0 in order to preserve the
color filter blending formula string the same (with the exception of
variable name change).
Shaders change in case of input color being needed:
- vec4 filteredColor;
- filteredColor = (((1.0 - uFilterColor.a) * output_Stage0) + uFilterColor);
- fsColorOut = filteredColor;
+ vec4 output_Stage1;
+ { // Stage 1: ModeColorFilterEffect
+ output_Stage1 = (((1.0 - uFilterColor_Stage1.a) * output_Stage0) + uFilterColor_Stage1);
+ }
+ fsColorOut = output_Stage1;
Shaders change in case of input color being not needed:
-uniform vec4 uFilterColor;
-in vec4 vColor;
+uniform vec4 uFilterColor_Stage0;
out vec4 fsColorOut;
void main() {
- vec4 filteredColor;
- filteredColor = uFilterColor;
- fsColorOut = filteredColor;
+ vec4 output_Stage0;
+ { // Stage 0: ModeColorFilterEffect
+ output_Stage0 = uFilterColor_Stage0;
+ }
+ fsColorOut = output_Stage0;
}
R=bsalomon@google.com, robertphillips@google.com, jvanverth@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/25023003
git-svn-id: http://skia.googlecode.com/svn/trunk@11912 2bbb7eff-a529-9590-31e7-b0007b416f81
There's a scenario that we're currently not allowing for, but I'd really like to use in DM:
1) client calls add(SomeRunnable*) several times
2) client calls wait()
3) any of the runnables added by the client _themselves_ call add(SomeOtherRunnable*)
4-inf) maybe those SomeOtherRunnables too call add(SomeCrazyThirdRunnable*), etc.
Right now in this scenario we'll assert in debug mode in step 3) when we call
add() and we're waiting to stop, and do strange unspecified things in release
mode.
The old threadpool had basically two states: running, and waiting to stop. If
a thread saw we were waiting to stop and the queue was empty, that thread shut
down. This wasn't accounting for any work that other threads might be doing;
potentially they were about to add to the queue.
So now we have three states: running, waiting, and halting. When the client
calls wait() (or the destructor triggers), we move into waiting. When a thread
notices we're _really_ done, that is, have an empty queue and there are no
active threads, we move into halting. The halting state actually triggers the
threads to stop, which wait() is patiently join()ing on.
BUG=
R=bungeman@google.com, bsalomon@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/26389005
git-svn-id: http://skia.googlecode.com/svn/trunk@11852 2bbb7eff-a529-9590-31e7-b0007b416f81
