Reason for revert:
This causes a syntax error.
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_compile_dbg_ng/builds/87819/steps/compile%20%28with%20patch%29/logs/stdio
Original issue's description:
> Implement canComputeFastBounds() for image filters.
>
> Image filters have never implemented this check, which means that
> filters which affect transparent black falsely claim they can compute
> their bounds.
>
> Implemented an affectsTransparentBlack() virtual for image
> filters, and a similar helper function for color filters.
>
> This will affect the following GMs: imagefiltersscaled
> (lighting, perlin noise now filter to clip),
> colorfilterimagefilter (new test case), imagefiltersclipped
> (perlin noise now filters to clip).
>
> Note: I de-inlined SkPaint::canComputeFastBounds() to avoid adding
> a dependency from SkPaint.h to SkImageFilter.h.h. Skia benches show
> no impact from this change, but will watch the perf bots carefully.
>
> BUG=4212
>
> Committed: https://skia.googlesource.com/skia/+/915881fe743f9a789037695f543bc6ea189cd0cbTBR=reed@google.com,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=4212
Review URL: https://codereview.chromium.org/1300403003
Image filters have never implemented this check, which means that
filters which affect transparent black falsely claim they can compute
their bounds.
Implemented an affectsTransparentBlack() virtual for image
filters, and a similar helper function for color filters.
This will affect the following GMs: imagefiltersscaled
(lighting, perlin noise now filter to clip),
colorfilterimagefilter (new test case), imagefiltersclipped
(perlin noise now filters to clip).
Note: I de-inlined SkPaint::canComputeFastBounds() to avoid adding
a dependency from SkPaint.h to SkImageFilter.h.h. Skia benches show
no impact from this change, but will watch the perf bots carefully.
BUG=4212
Review URL: https://codereview.chromium.org/1296943002
SkTemplates.h contains a number of Skia specific utilities which are
not designed for external use. In addition to reducing the external
support burden, this will allow Skia to freely refactor this file.
Review URL: https://codereview.chromium.org/1272293004
This also:
makes the SkLightingShader handle normal maps where the rects aren't aligned between the diffuse and normal maps.
adds a light aggregating class (Lights) to SkLightingShader (along with a Builder nested class).
Split out of https://codereview.chromium.org/1261433009/ (Add SkCanvas::drawLitAtlas call)
Review URL: https://codereview.chromium.org/1291783003
By adding a cast to SK_ARRAY_COUNT, the compiler treats the
compile-time value as if it were a const int, and like regular
numbers, permits it to be compared to signed and unsigned
numbers freely.
R=reed@google.com
Review URL: https://codereview.chromium.org/1299943002
We don't want to test small images on Gold because they are
not interested to look at. Instead, I wrote a unit test to
verify that scaling small images does not cause crashes.
BUG=skia:
Review URL: https://codereview.chromium.org/1287863004
Old flow to serialize a picture:
1) serialize picture ops
2) serialize all sub pictures recursively
3) flatten the rest of this picture into a buffer, deduping flattenable factories and typefaces as we go
4) serialize the factories and typefaces
5) serialize the bytes from 3)
This allows the data in step 5) to refer to the deduplicated factories and typefaces from step 4). But, each sub picture in step 2) is completely siloed, so they can't dedup with the parent picture or each other.
New flow:
1) serialize picture ops
2) flatten the rest of this picture into a buffer, deduping flattenable factories and typefaces as we go
3) dummy-serialize sub pictures into /dev/null, with the effect of adding any new typefaces to our dedup set
4) serialize the factories and typefaces
5) serialize the bytes from 2)
6) serialize all sub pictures recursively, with perfect deduplication because of step 3).
Now all typefaces in the top-level picture and all sub pictures recursively should end up deduplicated in the top-level typeface set.
Decoding changes are similar: we just thread through the top-level typefaces to the sub pictures. What's convenient / surprising is that this new code correctly reads old pictures if we just have each picture prefer its local typeface set over the top-level one: old pictures always just use their own typefaces, and new pictures always use the top-level ones.
BUG=skia:4092
Review URL: https://codereview.chromium.org/1233953004
Added comment about how computeInvariantOutput() is non-recursive in GrFragmentProcessor
Made isEqual() recursive in GrFragmentProcessor
BUG=skia:4182
Review URL: https://codereview.chromium.org/1287343005
Fixed wrong indent
Changed auto child advance back to backwards linear search for getting subset of coords and samplers array of a child
Used offset from parent instead of backwards linear search to find a child proc's coords and transforms in Auto...Advance
append mangleString to variable name in nameVariable()
BUILDS! Added AutoFragmentChildProcAdvance class; fixed a few errors from previous commits
BUG=skia:4182
Review URL: https://codereview.chromium.org/1286293002
Currently, SkPaintFilterCanvas does not provide any help in cloning
target canvas state. While that could be handled in subclasses, it is
easy to miss (see linked bug).
This CL adds a new constructor variant which ensures that the initial
matrix and clip bounds are inherited from the target canvas.
BUG=516790
R=reed@google.com,robertphillips@google.com
Review URL: https://codereview.chromium.org/1294013002
To do this, create SkImageCacherator, which wraps a generator and provides an
interface to get a cached answer for either the raster or texture output of
the generator.
BUG=skia:
Review URL: https://codereview.chromium.org/1291803002
Prior to this patch clients who were solely uploading to textures (e.g., SW Mask Mgr) would cause extra flushes b.c., even though kPreferNoIO was being specified, resources with pending IO would still be returned even though there was plenty of space in the resource cache.
Review URL: https://codereview.chromium.org/1286203002
This allows removal the difficult to use (and so currently unused)
placement new and related macros to allow any constructor of T to
be used to initilize the storage of SkTLazy. This also properly
aligns the SkTLazy storage.
Review URL: https://codereview.chromium.org/1283183003
Changed childProcessor(i) to return const referencd
Fixed rootProc/parentProc offset issues; renamed a few things.
added nonempty check to gatherTransforms to avoid segfault
removed recursive append_gr_coord_transforms() from GrGLProgramBuilder
BUILDS! Changed num*includeProc() calls to num() calls
added gatherCoordTransforms(). added coordTransforms() for root proc only
Modified GrFragmentProcessor to append child proc transforms and textures to root proc's arrays.
BUG=skia:4182
Review URL: https://codereview.chromium.org/1275853005
Previously, many of our codec implementations followed the same
pattern (often in a function named handleRewind):
switch (this->rewindIfNeeded()) {
case CouldNotRewind:
return CouldNotRewind;
case NoRewindNecessary:
// keep going
break;
case Rewound:
<re-read header etc>
break;
}
In this CL, remove the enum, and put the piece that happens in the
Rewound case into a virtual function, onRewind. rewindIfNeeded now
contains the common pieces from various functions named handleRewind.
In SkBmpCodec, add a function that returns whether the BMP is in ICO,
so it can have a common implementation for onRewind.
BUG=skia:3257
Review URL: https://codereview.chromium.org/1288483002
This requires adding the stroke info to the cache key, and doing the
stroking and dashing before rendering as triangles.
BUG=skia:3755
Review URL: https://codereview.chromium.org/1275553002
Paths are cached as tessellated triangle meshes in vertex buffers on the GPU. Stroked paths are not (yet) cached.
Paths containing no curved segments (linear paths) are reused at all scales. Paths containing curved segments are reused within a scale tolerance threshold.
In order to invalidate the cache when an SkPath is changed or deleted,
this required implementing genID change notification in SkPath. This is
modelled almost exactly on SkPixelRef::GenIDChangeListener.
However, It does not currently implement the check for unique genIDs,
so notifiers will fire when the first instance of an SkPathRef
using a given genID is destroyed.
Another caveat is that you cannot successfully add a change notifier
to an empty path, since it uses the "canonical" empty path which is
never modified or destroyed. For this reason, we prevent adding
listeners to it.
BUG=skia:4121,skia:4122, 497403
DOCS_PREVIEW= https://skia.org/?cl=1114353004
Committed: https://skia.googlesource.com/skia/+/468dfa72eb6694145487be17876804dfca3b7adb
Review URL: https://codereview.chromium.org/1114353004
Prior to this CL, if a client wanted to decode scanlines, they had to
create an SkCodec in order to get an SkScanlineDecoder. This introduces
complications if input data is not easily shared between the two
objects.
Instead, add methods to SkScanlineDecoder for creating a new one from
input data, and remove the creation functions from SkCodec.
Update DM and tests.
Review URL: https://codereview.chromium.org/1267583002
Does not try to cache calls to readPixels at the moment:
- not triggered by drawing
- not clear if we want to perform any pixel transformations (that readPixels allows) on the GPU or CPU
Can consider that another time.
BUG=513695
Review URL: https://codereview.chromium.org/1262923003
Paths are cached as tessellated triangle meshes in vertex buffers on the GPU. Stroked paths are not (yet) cached.
Paths containing no curved segments (linear paths) are reused at all scales. Paths containing curved segments are reused within a scale tolerance threshold.
In order to invalidate the cache when an SkPath is changed or deleted,
this required implementing genID change notification in SkPath. This is
modelled almost exactly on SkPixelRef::GenIDChangeListener.
However, It does not currently implement the check for unique genIDs,
so notifiers will fire when the first instance of an SkPathRef
using a given genID is destroyed.
Another caveat is that you cannot successfully add a change notifier
to an empty path, since it uses the "canonical" empty path which is
never modified or destroyed. For this reason, we prevent adding
listeners to it.
BUG=skia:4121,skia:4122, 497403
DOCS_PREVIEW= https://skia.org/?cl=1114353004
Review URL: https://codereview.chromium.org/1114353004
Renames Sk4pxXfermode.h to SkXfermode_opts.h,
and refactors it a tiny bit internally.
This moves xfermode optimization from being "compile-time everywhere but NEON"
to simply "runtime everywhere". I don't anticipate any effect on perf or
correctness.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1264543006
With this new arrangement, the benefits of inlining sk_memset16/32 have changed.
On x86, they're not significantly different, except for small N<=10 where the inlined code is significantly slower.
On ARMv7 with NEON, our custom code is still significantly faster for N>10 (up to 2x faster). For small N<=10 inlining is still significantly faster.
On ARMv7 without NEON, our custom code is still ridiculously faster (up to 10x) than inlining for N>10, though for small N<=10 inlining is still a little faster.
We were not using the NEON memset16 and memset32 procs on ARMv8. At first blush, that seems to be an oversight, but if so it's an extremely lucky one. The ARMv8 code generation for our memset16/32 procs is total garbage, leaving those methods ~8x slower than just inlining the memset, using the compiler's autovectorization.
So, no need to inline any more on x86, and still inline for N<=10 on ARMv7. Always inline for ARMv8.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1270573002
