SkOnceFlag is now statically initializable on all platforms.
Also adds sk_atomic_cas, used to implement new SkSpinlock.
Going to punt on making SkOnceFlag any smaller (for now, it's 8 bytes). We could conceivably get it down to two bits, one for done and one for a one-bit spinlock (we'd need atomic-& and atomic-| to make that work, but they appear to be available everywhere).
BUG=skia:1929
R=bungeman@google.com, reed@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/123093002
git-svn-id: http://skia.googlecode.com/svn/trunk@12968 2bbb7eff-a529-9590-31e7-b0007b416f81
To do this, this patch changes the "offset/loc" parameter in filterImage() / onFilterImage() from an inout-param to an out-param only, so that the calling filter can know how much the input filter wants its result offset (and doesn't include the original primitive position). This offset can then be applied to the current filter's crop rect. (I've renamed the parameter "offset" in all cases to make this clear.) This makes the call sites in SkCanvas/SkGpuDevice responsible for applying the resulting offset to the primitive's position, which is actually a fairly small change.
This change also fixes SkTileImageFilter and SkOffsetImageFilter to correctly handle an input offset, which they weren't before. This required modifying the GM's, since they assumed the broken behaviour.
NOTE: this will require rebaselining the imagefiltersgraph test, since it has a new test case.
NOTE: this will "break" the Blink layout tests css3/filters/effect-reference-subregion-chained-hw.html and css3/filters/effect-reference-subregion-hw.html, but it actually makes them give correct results. It should be suppressed on the skia roll, and I'll rebaseline it.
R=reed@google.com
Review URL: https://codereview.chromium.org/112803004
git-svn-id: http://skia.googlecode.com/svn/trunk@12895 2bbb7eff-a529-9590-31e7-b0007b416f81
This works in a way that is similar to SkData.
SkMallocPixelRef::NewWithProc
Motivation: Chrome has a ETC1PixelRef which calls delete[] on the
pixles on destruction. There is no reason for them to almost
duplicate our class, when we can provide them a more flexible
class. Example use:
static void delete_uint8_proc(void* ptr, void*) {
delete[] static_cast<uint8_t>(ptr);
}
SkPixelRef* new_delete_pixref(const SkImageInfo& info,
SkColorTable* ctable) {
size_t rb = info.minRowBytes();
return SkMallocPixelRef::NewWithProc(
info, rb, ctable,
new uint8_t[info.getSafeSize(rb)],
delete_uint8_proc, NULL);
}
SkMallocPixelRef::NewWithData
Motivation: This allows up to eliminate SkDataPixelRef. We
modified SkImage_Raster to use MallocPixelRef rather than
SkDataPixlRef.
Also: Unit tests in tests/MallocPixelRefTest.
BUG=
R=reed@google.com
Review URL: https://codereview.chromium.org/106883006
git-svn-id: http://skia.googlecode.com/svn/trunk@12861 2bbb7eff-a529-9590-31e7-b0007b416f81
Motivation: We want to remove redundant classes from Skia. To
that end we want to remove SkImageRef and its subclasses and
replace their uses with SkDiscardablePixelRef +
SkDecodingImageGenerator. Since Android uses SkImageRef, we need
to make sure that SkDecodingImageGenerator allows all of the
settings that Android exposes in BitmapFactory.Options.
To that end, we have created an Options struct for the
SkDecodingImageGenerator which lets the client of the generator set
sample size, dithering, and bitmap config.
We have made the SkDecodingImageGenerator constructor private
and replaced the SkDecodingImageGenerator::Install functions
with a SkDecodingImageGenerator::Create functions (one for
SkData and one for SkStream) which now take a
SkDecodingImageGenerator::Options struct.
Also added a ImageDecoderOptions test which loops through a list
of sets of options and tries them on a set of 5 small encoded
images.
Also updated several users of SkDecodingImageGenerator::Install to
follow new call signature - gm/factory.cpp, LazyDecodeBitmap.cpp,
and PictureTest.cpp, CachedDecodingPixelRefTest.cpp.
We also added a new ImprovedBitmapFactory Test which simulates the
exact function that Android will need to modify to use this,
installPixelRef() in BitmapFactory.
R=reed@google.com, scroggo@google.com
Committed: https://code.google.com/p/skia/source/detail?r=12744
Review URL: https://codereview.chromium.org/93703004
git-svn-id: http://skia.googlecode.com/svn/trunk@12855 2bbb7eff-a529-9590-31e7-b0007b416f81
Motivation: We want to remove redundant classes from Skia. To
that end we want to remove SkImageRef and its subclasses and
replace their uses with SkDiscardablePixelRef +
SkDecodingImageGenerator. Since Android uses SkImageRef, we need
to make sure that SkDecodingImageGenerator allows all of the
settings that Android exposes in BitmapFactory.Options.
To that end, we have created an Options struct for the
SkDecodingImageGenerator which lets the client of the generator set
sample size, dithering, and bitmap config.
We have made the SkDecodingImageGenerator constructor private
and replaced the SkDecodingImageGenerator::Install functions
with a SkDecodingImageGenerator::Create functions (one for
SkData and one for SkStream) which now take a
SkDecodingImageGenerator::Options struct.
Also added a ImageDecoderOptions test which loops through a list
of sets of options and tries them on a set of 5 small encoded
images.
Also updated several users of SkDecodingImageGenerator::Install to
follow new call signature - gm/factory.cpp, LazyDecodeBitmap.cpp,
and PictureTest.cpp, CachedDecodingPixelRefTest.cpp.
We also added a new ImprovedBitmapFactory Test which simulates the
exact function that Android will need to modify to use this,
installPixelRef() in BitmapFactory.
R=reed@google.com, scroggo@google.com
Review URL: https://codereview.chromium.org/93703004
git-svn-id: http://skia.googlecode.com/svn/trunk@12744 2bbb7eff-a529-9590-31e7-b0007b416f81
Skia cannot use Chromium's implementation of mutex (Lock) due to static
initializers. However, we would like to be able to use Chromium's
implementation of atomics. This motivates the split of implementation.
Skia's atomic and mutex calls should be inlinable, especially the atomics.
These calls often compile down to very few instructions, and we currently have
the overhead of a function call. This motivates the header implementation.
There is still a desire for the build system to select the implementation, so
the SK_XXX_PLATFORM_H pattern for header files is introduced. This allows the
build system to control which platform specific header files are chosen.
The Chromium side changes (most of which will need to go in before this change
can be found at https://codereview.chromium.org/19477005/ .
The Chromium side changes after this lands can be seen at
https://codereview.chromium.org/98073013 .
Review URL: https://codereview.chromium.org/19808007
git-svn-id: http://skia.googlecode.com/svn/trunk@12738 2bbb7eff-a529-9590-31e7-b0007b416f81
Revert "Revert "PixelRef now returns (nearly) everything that is currently in SkBitmap. The goal is to refactor bitmap later to remove redundancy, and more interestingly, remove the chance for a disconnect between the actual (pixelref) rowbytes and config, and the one claimed by the bitmap.""""""
This reverts commit eabd6b2ed4e494b323c08f32358f45950a0368c3.
BUG=
Review URL: https://codereview.chromium.org/108773003
git-svn-id: http://skia.googlecode.com/svn/trunk@12624 2bbb7eff-a529-9590-31e7-b0007b416f81
Added SK_API to SkImageGenerator (already in include/).
Moved SkDiscardablePixelRef::Install to SkInstallDiscardablePixelRef,
added SK_API to that function, and moved declaration to
SkImageGenerator.h
This keeps the SkDiscardablePixelRef internal to Skia, but exposes a
method to install it into a bitmap.
Modifed tests that rely on this functio to use new version.
BUG=
R=mtklein@google.com, reed@google.com
Review URL: https://codereview.chromium.org/111713002
git-svn-id: http://skia.googlecode.com/svn/trunk@12612 2bbb7eff-a529-9590-31e7-b0007b416f81
This also includes some changes to the xfermodeimagefilter and tileimagefilter GMs to properly handle the CTM. This worked before only because SkBitmapSource was ignoring the CTM. Now that it respects it, we need to give the correct transform. This also means the GMs now work while zoomed. It also implements CTM support for SkTileImageFilter.
NOTE: this will require rebaselining a number of imagefilter GMs on Nexus4, since they render in perspective (using the CTM). The changes to the results should all be improvements.
R=reed@google.com, robertphillips@google.com
Review URL: https://codereview.chromium.org/106933002
git-svn-id: http://skia.googlecode.com/svn/trunk@12571 2bbb7eff-a529-9590-31e7-b0007b416f81
This makes sense since Android will be giving us a stream and the
decoders expect a stream. This also removes some glue code,
DecodeMemoryToTarget, that works better using a SkImageGenerator.
Motivation: This is a necessary step to move from SkImageRef to
SkDiscardablePixelRef.
SkImageDecoder::DecodeMemoryToTarget function removed.
BUG=
R=reed@google.com, scroggo@google.com
Review URL: https://codereview.chromium.org/101973005
git-svn-id: http://skia.googlecode.com/svn/trunk@12560 2bbb7eff-a529-9590-31e7-b0007b416f81
Note: I initially implemented this as a fully-generic SkResizeImageFilter, but then I realized that the dstRect should always be transformed by the filter matrix, but that the srcRect should not (since it's specified relative to the dimensions of the original bitmap). Since this would be confusing for someone attempting to use this as a generic resizing filter, I decided to build the functionality into SkBitmapSource instead.
BUG=
R=reed@google.com
Review URL: https://codereview.chromium.org/106933002
git-svn-id: http://skia.googlecode.com/svn/trunk@12522 2bbb7eff-a529-9590-31e7-b0007b416f81
Removed SkBitmapFactory since no clients were using it. New cache
selection mechanism can simply pass a SkDiscardableMemory::Factory
into the SkDiscardablePixelRef if non-default SkDiscardableMemory
should be used. Removed BitmapFactoryTest.
SkDiscardableMemory::Factory interface. Android will need this
functionality in the future inside their BitmapFactory.
Removed SkLazyPixelRef, since it's functionality is now subsumed into
SkDiscardablePixelRef. Removed LazyPixelRef test.
Modified SkDiscardablePixelRef to optionally allow it to use a
SkDiscardableMemory::Factory. This tiny change makes it a replacement
for SkLazyPixelRef. This functioanlity is also necessary for moving
Android over to SkDiscardablePixelRef from SkImageRef in a later CL.
Added a test for this.
SkDecodingImageGenerator::Install can optionally pass a factory in to
SkDiscardablePixelRef.
Removed SkImageCache, SkLruImageCache, and SkPurgeableImageCache.
This functionality can be handled much more cleanly by
SkDiscardableMemory.
New SkDiscardableMemoryPool class to replace SkLruImageCache. In a
later CL, we will replace SkImageRef_GlobalPool (used by android) as
well. This is a concrete implementation of
SkDiscardableMemory::Factory. Added a test for this.
modified gm/factory.cpp to remove dependnce on SkBitmapFactory +
SkLruImageCache. Now uses SkDecodingImageGenerator +
SkDiscardablePixelRef + SkDiscardableMemoryPool.
SkImageDecoder::Target replaces SkBitmapFactory::Target. The
DecodeMemoryToTarget function may disappear in the future.
Moved SkLazyCachingPixelRef::DecodeProc replaces
SkBitmapFactory::DecodeProc. This is a short term change, since
another CL changes SkLazyCachingPixelRef to use SkImageGenerator
instead of DecodeProc.
Modified DrawBitmapRectTest to use SkDiscardablePixelRef instead of
SkLazyPixelRef.
tools/LazyDecodeBitmap.cpp now uses SkDecodingImageGenerator +
SkDiscardablePixelRef instead of a SkBitmapFactory.
bench_pictures uses the Global SkDiscardableMemoryPool instead of a
global gLruImageCache.
R=reed@google.com, scroggo@google.com
Review URL: https://codereview.chromium.org/103033002
git-svn-id: http://skia.googlecode.com/svn/trunk@12515 2bbb7eff-a529-9590-31e7-b0007b416f81
Add INHERITED declarations to class declarations that prevent
compilation with the flag.
Remove SK_DEFINE_INST_COUNT from all class implementations. Instead,
use function-local static variables in the reference count helper
classes to create the global instances to store the needed info. The
accessor functions are defined inline in the helper classes, so
definitions are not needed. The initialization point of the variables
should be as well defined as previously.
Remove SK_DECLARE_INST_COUNT_TEMPLATE and use SK_DECLARE_INST_COUNT
instead. This avoids possible future compilation errors further.
For SK_ENABLE_INST_COUNT=0 compilation, add an empty static member
function to all classes that use SK_DECLARE_INST_COUNT and
SK_DECLARE_INST_COUNT_ROOT macros. The function ensures that classes
contain public INHERITED typedef. This member function seems to be
compiled away. This shouĺd ensure that part of the compilation errors
are caught earlier.
Also adds DSK_DECLARE_INST_COUNT to few SkPDFDict subclasses.
R=robertphillips@google.com, richardlin@chromium.org, bsalomon@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/98703002
git-svn-id: http://skia.googlecode.com/svn/trunk@12501 2bbb7eff-a529-9590-31e7-b0007b416f81
While it doesn't matter on Windows, mingw on case-sensitive OSes uses all lower case filenames for platform include files. I found the problem in SkCondVar.h from Mozilla checkout of skia sources, but the patch contains a fix for the whole skia tree.
R=bungeman@google.com
Review URL: https://codereview.chromium.org/99173003
git-svn-id: http://skia.googlecode.com/svn/trunk@12461 2bbb7eff-a529-9590-31e7-b0007b416f81
I'm working on some code that's much faster when compiled by GCC than by Clang
because GCC inlines more aggressively. Using SK_ATTRIBUTE(always_inline) on
the appropriate methods narrows the performance gap considerably.
This should work for MSVC, GCC, and Clang, otherwise falling back to "inline".
BUG=
R=reed@google.com
Review URL: https://codereview.chromium.org/83333005
git-svn-id: http://skia.googlecode.com/svn/trunk@12364 2bbb7eff-a529-9590-31e7-b0007b416f81
Adds "grresourcecache_add" and "grresourcecache_find" bench tests to test
GrResourceCache::add and GrResourceCache::find. The tests work only
with GPU backends, since GrResourceCache needs an GrGpu.
Modifies bench tests to override SkBenchmark::isSuitableFor(Backend)
function that specifies what kind of backend the test is inteded
for. This replaces the previous "fIsRendering" flag that would
indicate test that did no rendering.
Adds SkCanvas::getGrContext() call to get the GrContext that the
canvas ends up drawing to. The member function solves a common
use-case that is also used in the benchmark added here.
R=mtklein@google.com, bsalomon@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/73643005
git-svn-id: http://skia.googlecode.com/svn/trunk@12334 2bbb7eff-a529-9590-31e7-b0007b416f81
Using Mike Klein's excellent coverage tool, increase the
unit testing of SkPath.cpp from 70% to 95%.
Along the way, determined that these functions were not
maintained or used:
SkPath::pathTo
SkPath::contains
as well as a large block of SkPath::cheapGetDirection().
Changed SkPath::validate() to permit infinities in
the path data points.
Fixed errors in preserving direction.
Fixed error setting direction when convexity is unknown.
Added missing conic to moveTo only detector.
BUG=
R=bsalomon@google.com, reed@google.com
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/65493004
git-svn-id: http://skia.googlecode.com/svn/trunk@12291 2bbb7eff-a529-9590-31e7-b0007b416f81
Recent changes to SkBitmapDevice modified ::drawRRect() to take
an optimized drawing case. Some subclasses of SkBitmapDevice were
depending on the old behavior of calling ::drawPath(). Since they
do not draw, attempting to take the drawing path can cause problems.
For these subclasses, call drawPath() in the subclass.
R=reed@google.com, robertphillips@google.com
Review URL: https://codereview.chromium.org/70443002
git-svn-id: http://skia.googlecode.com/svn/trunk@12247 2bbb7eff-a529-9590-31e7-b0007b416f81
SK_CONF_TRY_SET() is like SK_CONF_SET(), but doesn't complain if
confname can't be found. This is useful if the SK_CONF_DECLARE is
inside a source file whose linkage is dependent on the system.
Internally to the SkRTConf system, SkRTConfRegistry::set() was given
an additional parameter controling wanrings.
A new RuntimeConfig unit test was introduced. It should run silently.
In the future, it should be expanded to cover all of the SkRTConf
functionality.
(For example, the images.jpeg.suppressDecoderWarnings variable is
defined and used only in SkImageDecoder_libjpeg.cpp, but on MacOS, we
use Core Graphics via SkImageDecoder_CG.cpp - SkImageDecoder_libjpeg
is never linked in. The same is true of the Windows Imaging Component
on Windows.)
BUG=
R=reed@google.com
Review URL: https://codereview.chromium.org/54503007
git-svn-id: http://skia.googlecode.com/svn/trunk@12155 2bbb7eff-a529-9590-31e7-b0007b416f81
The reason for this CL is to allow greater decoder flexibility.
Chrome currently uses its own decoding functions. These allow for
greater flexibility in dealing with images with multiple frames or
partial data. The DecodeProc function was not flexible enough to
handle these. Instead of asking the decoder to squeeze everything
into the DecodeProc, we now ask the downstream library to inherit from
SkCachingPixelRef. If WebKit's LazyDecodingPixelRef is re-tooled to
inherit from SkCachingPixelRef, then it can make use of Skia's caching
ability while still allowing it to deal with multiple frames, scaling,
subsetting, and partial data.
- The abstract SkCachingPixelRef class handles caching the decoded
data in a SkScaledImageCache. This class relies on the virtual
functions onDecodeInfo() and onDecode() to do the actual decoding
of data.
- The SkLazyCachingPixelRef class is derived from SkCachingPixelRef.
It provides an implementation of onDecodeInfo() and onDecode() in
terms of calls to a SkBitmapFactory::DecodeProc function. It also
provides an Install() static method which installs a new
SkLazyCachingPixelRef into a SkBitmap.
SkLazyCachingPixelRef exists for two reasons: to test
SkCachingPixelRef within Skia and as an example for downstream
developers to make their own classes that inherit from
SkCachingPixelRef.
- The CachedDecodingPixelRefTest was updated to test the
SkLazyCachingPixelRef class and indirectly the SkCachingPixelRef
class.
BUG=
R=reed@google.com, scroggo@google.com
Author: halcanary@google.com
Review URL: https://codereview.chromium.org/54203006
git-svn-id: http://skia.googlecode.com/svn/trunk@12149 2bbb7eff-a529-9590-31e7-b0007b416f81
Fixes the cases where clip stack reduction would cause clip to be
re-rendered to stencil for each draw call. This causes unneeded
slowdown.
Stencil cache would not be used because the clip stack generation id communicated
by the clip stack element list would be invalid. This happended due to
a) clip stack reduction creating new elements in the element list.
b) purging logic removing the generation id, but reduction logic
selecting already purged element, and thus the generation id, as
the representative state of the clip.
Cases of a) where reduction would flatten the stack to a single new
element were fixed by assigning the generation id of the top-most
element of the clip stack as the generation id of the new
element. This is not strictly minimal, but enables more caching than
using invalid id.
Cases of a) where reduction would substitute a stack element with a
new element the generation id of the substituted element is used.
The b) part was fixed by removing the purging logic. It was not
exactly correct, as the previously purged states were actually
used. The purging was not used for anything.
Changes SkClipStack API to highlight that invalid generation id is
never returned by SkClipStack. Empty stacks are wide open. Changes the
clients to reflect this.
Fixes a crash when not passing anti-alias out parameter to
GrReducedClip::ReduceClipStack. The crash is not exercised in the
current code.
Committed: http://code.google.com/p/skia/source/detail?r=12084R=bsalomon@google.com, robertphillips@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/48593003
git-svn-id: http://skia.googlecode.com/svn/trunk@12127 2bbb7eff-a529-9590-31e7-b0007b416f81
Fixes the cases where clip stack reduction would cause clip to be
re-rendered to stencil for each draw call. This causes unneeded
slowdown.
Stencil cache would not be used because the clip stack generation id communicated
by the clip stack element list would be invalid. This happended due to
a) clip stack reduction creating new elements in the element list.
b) purging logic removing the generation id, but reduction logic
selecting already purged element, and thus the generation id, as
the representative state of the clip.
Cases of a) where reduction would flatten the stack to a single new
element were fixed by assigning the generation id of the top-most
element of the clip stack as the generation id of the new
element. This is not strictly minimal, but enables more caching than
using invalid id.
Cases of a) where reduction would substitute a stack element with a
new element the generation id of the substituted element is used.
The b) part was fixed by removing the purging logic. It was not
exactly correct, as the previously purged states were actually
used. The purging was not used for anything.
Changes SkClipStack API to highlight that invalid generation id is
never returned by SkClipStack. Empty stacks are wide open. Changes the
clients to reflect this.
Fixes a crash when not passing anti-alias out parameter to
GrReducedClip::ReduceClipStack. The crash is not exercised in the
current code.
R=bsalomon@google.com, robertphillips@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/48593003
git-svn-id: http://skia.googlecode.com/svn/trunk@12084 2bbb7eff-a529-9590-31e7-b0007b416f81
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
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
This change removes sk_stdint.h since it is only needed for vs2008 and earlier.
This change removes SK_MMAP_SUPPORT define since it is no longer used.
This change removes the stdio.h include from SkTypes.h since on many systems
this is a very large header, few Skia files actually use it, it is
available everywhere standard, and SkDebugf should be used instead.
After this change there is no need for external users to put Skia's
include/config into their own list of includes, saving the headache
of having two header files of the same name and sometimes getting the
wrong one depending on include order.
R=bsalomon@google.com, djsollen@google.com
Review URL: https://codereview.chromium.org/27044002
git-svn-id: http://skia.googlecode.com/svn/trunk@11738 2bbb7eff-a529-9590-31e7-b0007b416f81
Sometimes, when ScriptShape is presented with a surrogate pair which does
not map to a glyph, it returns two space glyphs instead of .notdef (0).
Detect this class of issues and handle appropriately.
git-svn-id: http://skia.googlecode.com/svn/trunk@11660 2bbb7eff-a529-9590-31e7-b0007b416f81
I noticed SkMatrix <-> SkMatrix44 conversions were dropping the
perspective values on the floor. As we use SkMatrix44 heavily in
Chromium, I'm concerned this missing code will cause a bug eventually.
It should be correct to simply use the bottom row of the 4x4 matrix
excluding the third column.
Previously committed and reverted, second attempt with fix for
incorrect use of SkMScalar/SkScalar.
BUG=
R=reed@google.com, caryclark@google.com
Author: aelias@chromium.org
Review URL: https://codereview.chromium.org/25484006
git-svn-id: http://skia.googlecode.com/svn/trunk@11624 2bbb7eff-a529-9590-31e7-b0007b416f81
I noticed SkMatrix <-> SkMatrix44 conversions were dropping the
perspective values on the floor. As we use SkMatrix44 heavily in
Chromium, I'm concerned this missing code will cause a bug eventually.
It should be correct to simply use the bottom row of the 4x4 matrix
excluding the third column.
BUG=
R=reed@google.com
Author: aelias@chromium.org
Review URL: https://codereview.chromium.org/25484006
git-svn-id: http://skia.googlecode.com/svn/trunk@11622 2bbb7eff-a529-9590-31e7-b0007b416f81
Before, gradients would only interpolate the linear portion of the
quadratic equation if there was no perspective. This updates them to
do so even in the case that there is perspective. The rearrangement
of math causes noise differences in the following gm tests:
gradients_no_texture_gpu
gradients_view_perspective_gpu
gradients_local_perspective_gpu
gradients_gpu
R=bsalomon@google.com
Author: cdalton@nvidia.com
Review URL: https://codereview.chromium.org/25645006
git-svn-id: http://skia.googlecode.com/svn/trunk@11595 2bbb7eff-a529-9590-31e7-b0007b416f81
To dodge the problem, call computeBounds when creating the global empty path
ref.
There's still another race here, which is that we can race to create the empty
path ref in the first place. As written we can conceivably allocate an
arbitrary number of empty path refs, one of which ends up pointed to by the
global variable at the end.
I've punted on fixing this for now because 1) tsan has not complained yet; 2) I
think it can be fixed by the same approach as we can fix the memsets in
25415003, so I want to wait to see how that review goes
first.
BUG=
R=reed@google.com, robertphillips@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/25745003
git-svn-id: http://skia.googlecode.com/svn/trunk@11576 2bbb7eff-a529-9590-31e7-b0007b416f81
Only implemented for PNG.
Add a getter and setter, and sets the default to false in the
constructor. Also copies the setting in copyFieldsToOther.
Fix an indpendent bug where fDitherImage was not being copied in
copyFieldsToOther.
In SkScaledBitmapSampler::begin, consolidate the settings passed in
by passing a const reference to the decoder. The decoder can be
referenced for its settings of dither, unpremultiplied, and now
skipping writing zeroes. Update callers to use the new API. In png
decoder, rather than passing around a pointer to an initial
read of getDitherImage, and potentially changing it, look at the
field on the decoder itself, and modify it directly. This is a
change in behavior - now if that same decoder is used to decode
a different image, the dither setting has changed. I think this is
okay because A) the typical use case is to use a new decoder for
each decode, B) we do not make any promises that a decode does not
change the decoder and C) it makes the code in SkScaledBitmapSampler
much cleaner.
In SkScaledBitmapScampler, add new row procs for skipping zeroes. Now
that choosing the row proc has five dimensions (src config, dst config,
dither, skip writing zeroes, unpremultiplied), use a new method: each
src/dst combination has a function for choosing the right proc depending
on the decoder.
SkScaledBitmapScampler::RowProc is now public for convenience.
Remove Sample_Gray_D8888_Unpremul, which is effectively no different
from Sample_Gray_D8888.
In cases where unpremultiplied was trivial, such as 565 and when
sampling from gray, decoding may now succeed.
Add a benchmark (currently disabled) for comparing the speed of skipping
writing zeroes versus not skipping. For this particular image, which is
mostly transparent pixels, normal decoding took about 3.6 milliseconds,
while skipping zeroes in the decode took only about 2.5 milliseconds
(this is on a Nexus 4). Presumably it would be slower on an image
with a small amount of transparency, but there will be no slowdown
for an image which reports that it has no transparency.
In SkImageRef_ashmem, always skip writing zeroes, since ashmem
memory is guaranteed to be initialized to 0.
Add a flag to skip writing zeroes in skimage.
Add a regression test for choosing the rowproc to ensure I did not
change any behavior accidentally.
BUG=skia:1661
R=reed@google.com
Review URL: https://codereview.chromium.org/24269006
git-svn-id: http://skia.googlecode.com/svn/trunk@11558 2bbb7eff-a529-9590-31e7-b0007b416f81
Adds a 'hasVertexCode' method to GrEffect and a 'fHasVertexCode' field
to GrGLProgramDesc::KeyHeader. Also adds a GrVertexEffect class that
effects have to inherit from in order to set the 'hasVertexCode' flag
and be able to emit vertex code, and updates the existing effects to
use it as needed.
R=bsalomon@google.com
Author: cdalton@nvidia.com
Review URL: https://codereview.chromium.org/23653059
git-svn-id: http://skia.googlecode.com/svn/trunk@11537 2bbb7eff-a529-9590-31e7-b0007b416f81
Extracts a GrCustomCoordsTextureEffect class from
GrSimpleTextureEffect. This way there are no effects that can
conditionally require a vertex shader. They either always need one or
never do. Also removes kCustom_CoordsType from the CoordsType enum in
GrEffect (that enum is really only meant for coords provided by the
framework), and updates GrSimpleTextureEffect::TestCreate to make the
effect with position as well, instead of just local coords.
R=bsalomon@google.com
Author: cdalton@nvidia.com
Review URL: https://codereview.chromium.org/24018007
git-svn-id: http://skia.googlecode.com/svn/trunk@11531 2bbb7eff-a529-9590-31e7-b0007b416f81
