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
This enables the NEON sk_float_rsqrt() code for configurations that have NEON at run-time but not compile-time.
These devices will see about a 2x (1.26 -> 2.33) slowdown in sk_float_rsqrt(), but it should be more precise than our portable fallback.
(When inlined, the portable fallback and the NEON code are almost identical in speed. The only difference is precision. Going through a function pointer is causing all this slowdown. This is a good example of a place where Skia really benefits from compile-time NEON.)
BUG=skia:4117,skia:4114
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1264893002
SDL isn't an OS anyway, it's just a library views can use. Remaining
support for Brew was removed some time ago, and there are currently
no uses of SK_BUILD_FOR_PALM.
Review URL: https://codereview.chromium.org/1268573002
This hasn't been tested for years, and no one currently knows when it
last worked (if ever). It is doubtful that any of the remaining logic
would even make sense with a modern version of Embedded Compact 2013.
Review URL: https://codereview.chromium.org/1260453008
The current include-what-you-use with current clang is much less
noisy and more useful than it has been in the past. This change
introduces a few IWYU directives (which are helpful documentation for
humans as well) and fixes a few sets of includes.
Review URL: https://codereview.chromium.org/1207893002
To make this work, we tag their pixelrefs as temporarily immutable, allowing
ourselves to restore the pixels to mutability only when the image drops away.
This should allow us to wobble back and forth between writing to the Surface
and reading from the Image without a COW, with the Surface seeing mutable
pixels and the Image seeing immutable pixels.
The big idea is, Image doesn't need forever-immutable pixels, it just needs
pixels that are immutable as long as it's alive.
BUG=skia:
patch from issue 804523002 at patchset 40001 (http://crrev.com/804523002#ps40001)
Review URL: https://codereview.chromium.org/1254383006
This reverts commit d12e6ffa5c.
Our Chrome roll canaries are failing with the dreaded
Ninja-says-there's-more-work-to-do message. I will break this up
smaller (if possible) and try again tomorrow.
BUG=skia:4126
Review URL: https://codereview.chromium.org/1258293004 .
include/views/SkOSWindow_Win.h includes it.
To move SkTHash.h to include/private, SkChecksum.h needs to go there too. To move SkChecksum.h to include/private, SkTLogic needs to go there too.
This adds a bunch of -Iinclude/private to tools.gyp I missed in the last CL.
No public API changes.
TBR=reed@google.com
BUG=skia:4126
Review URL: https://codereview.chromium.org/1260613006
This is a contract change for SkPath::getBounds(), which formally was defined to return 0,0,0,0 for a 1-point path, regardless of the coordinates of that point. This seems wacky/inconsistent, and was causing other bugs (incorrect bounds) when this was unioned with other rects.
Does anyone remember why we defined it this way?
BUG=513799
Review URL: https://codereview.chromium.org/1261773002
