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
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 .
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
SkSurface_Raster snapshots do not lock their backing bitmaps when the
pixel ref is shared - they only lock on deep-copy.
But since for raster surfaces the pixels are always in memory, I think
it would be OK to also lock in the former case.
This allows for optimized (zero-copy) reads of raster surface snapshot
data.
R=reed@google.com
Review URL: https://codereview.chromium.org/1256993002
Improves max relative error from 0.00175126 to 0.000650197.
Also add unit tests to check error bounds.
BUG=chromium:511458
Review URL: https://codereview.chromium.org/1251423002
Tidy up a little while I'm in here:
1) SIMD headers are now included by SkTypes.h as appropriate.
2) _mm_cvtss_f32() is pithier and generates the same code.
Looks like this is the only code checking for SSE wrong. After this CL:
~/skia (sse) $ git grep __SSE
include/core/SkPreConfig.h: #if defined(__SSE4_2__)
include/core/SkPreConfig.h: #elif defined(__SSE4_1__)
include/core/SkPreConfig.h: #elif defined(__SSE3__)
include/core/SkPreConfig.h: #elif defined(__SSE2__)
every other check is in SkPreConfig.h where it belongs.
This is going to affect some GMs subtly on Windows.
BUG=chromium:511458
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1248503004
This is split off of https://codereview.chromium.org/1225923010/ (Start tightening correspondence betweeen GrDrawContext and GrRenderTarget). It:
fixes some style nits
replaces some passing of GrContext with GrTextureProvider & GrDrawContext
does a bit of the finer grained creation of GrDrawContexts
Review URL: https://codereview.chromium.org/1245183002
Visual Studio 2015 has additional warnings around noexcept and
disabling exceptions, which can be worked around with the
(undocumented) _HAS_EXCEPTIONS macro.
Visual Studio 2013 and 2015 have roundf in math.h, so use it to
avoid extra work and casts.
We avoid using cmath, as it undefs isfinite on gcc, but Visual Studio
2015 no longer provides overloads of copysign from math.h (which is
actually correct). As a result, use copysignf (which is available in
math.h in 2013 and 2015) directly.
Review URL: https://codereview.chromium.org/1244173005
This deduplicates a few pieces of code:
- we end up with one copy of each xfer32() driver loop instead of one per xfermode;
- we end up with two* copies of each xfermode implementation instead of ten**.
* For a given Mode: Mode() itself and xfer_aa<Mode>().
** From unrolling: twice at a stride of 8, once at 4, once at 2, and once at 1, then all again for when we have AA.
This decreases the size of SkXfermode.o from 1.5M to 620K on x86-64 and from 1.3M to 680K on ARMv7+NEON.
If we wanted to, we could eliminate the xfer_aa<Mode>() copy by tagging each Mode() function as __attribute__((noinline)) or its equivalent. This would result in another ~100K space savings.
Performance is affected in proportion to the original xfermode speed:
fast modes like Plus take the largest proportional hit, and slow modes
like HardLight or SoftLight see essentially no hit at all.
This adds SK_VECTORCALL to help keep this code fast on ARMv7 and Windows. I've looked at the ARMv7 generated code... it looks good, even pretty.
For compatibility with SK_VECTORCALL, we now pass the vector-sized arguments by value instead of by reference. Some refactoring now allows us to declare each mode as just a static function instead of a struct, which simplifies things.
TBR=reed@google.com
No public API changes.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/e617e1525916d7ee684142728c0905828caf49da
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-Arm7-Debug-Android_NoNeon-Trybot
Review URL: https://codereview.chromium.org/1242743004
Reason for revert:
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-GCC-Arm7-Debug-Android_NoNeon/builds/1168/steps/build%20most/logs/stdio
Original issue's description:
> De-templatize Sk4pxXfermode code a bit.
>
> This deduplicates a few pieces of code:
> - we end up with one copy of each xfer32() driver loop instead of one per xfermode;
> - we end up with two* copies of each xfermode implementation instead of ten**.
>
> * For a given Mode: Mode() itself and xfer_aa<Mode>().
> ** From unrolling: twice at a stride of 8, once at 4, once at 2, and once at 1, then all again for when we have AA.
>
> This decreases the size of SkXfermode.o from 1.5M to 620K on x86-64 and from 1.3M to 680K on ARMv7+NEON.
>
> If we wanted to, we could eliminate the xfer_aa<Mode>() copy by tagging each Mode() function as __attribute__((noinline)) or its equivalent. This would result in another ~100K space savings.
>
> Performance is affected in proportion to the original xfermode speed:
> fast modes like Plus take the largest proportional hit, and slow modes
> like HardLight or SoftLight see essentially no hit at all.
>
> This adds SK_VECTORCALL to help keep this code fast on ARMv7 and Windows. I've looked at the ARMv7 generated code... it looks good, even pretty.
>
> For compatibility with SK_VECTORCALL, we now pass the vector-sized arguments by value instead of by reference. Some refactoring now allows us to declare each mode as just a static function instead of a struct, which simplifies things.
>
> TBR=reed@google.com
> No public API changes.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/e617e1525916d7ee684142728c0905828caf49daTBR=msarett@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1245273005
This deduplicates a few pieces of code:
- we end up with one copy of each xfer32() driver loop instead of one per xfermode;
- we end up with two* copies of each xfermode implementation instead of ten**.
* For a given Mode: Mode() itself and xfer_aa<Mode>().
** From unrolling: twice at a stride of 8, once at 4, once at 2, and once at 1, then all again for when we have AA.
This decreases the size of SkXfermode.o from 1.5M to 620K on x86-64 and from 1.3M to 680K on ARMv7+NEON.
If we wanted to, we could eliminate the xfer_aa<Mode>() copy by tagging each Mode() function as __attribute__((noinline)) or its equivalent. This would result in another ~100K space savings.
Performance is affected in proportion to the original xfermode speed:
fast modes like Plus take the largest proportional hit, and slow modes
like HardLight or SoftLight see essentially no hit at all.
This adds SK_VECTORCALL to help keep this code fast on ARMv7 and Windows. I've looked at the ARMv7 generated code... it looks good, even pretty.
For compatibility with SK_VECTORCALL, we now pass the vector-sized arguments by value instead of by reference. Some refactoring now allows us to declare each mode as just a static function instead of a struct, which simplifies things.
TBR=reed@google.com
No public API changes.
BUG=skia:
Review URL: https://codereview.chromium.org/1242743004
This change is motivated by a recent switch in how chromium handles
<video> color spaces, making rec709 more commonly used. This will
allow video -> canvas copies to take the fast GPU path when we're using
709, just as we do with 601 and jpeg.
Chromium-side change: https://codereview.chromium.org/1236313002
Review URL: https://codereview.chromium.org/1241723005
Motivation:
- perf win for clients that overwrite the surface after a snapshot.
- may allow us to eliminate SkDeferredCanvas, as this was its primary advantage.
BUG=skia:
Review URL: https://codereview.chromium.org/1236023004
The new test is disabled by default, as it's quite slow.
We can run it if we suspect problems by passing -x to DM.
This test would have been failing before the bug fix, and now is passing.
Assuming the Priv on the end means it's not considered public API...
TBR=reed@google.com
BUG=skia:4052
Review URL: https://codereview.chromium.org/1228333003
and are treated as convex when they are not.
Allow the SkPath::Iter to leave degenerate path
segments unmolested by passing an additional exact
bool to next().
Treat any non-zero length as significant in addPt().
R=reed@google.com,robertphillips@google.com
BUG=493450
Review URL: https://codereview.chromium.org/1228383002
The error log is as follows:
../../third_party/skia/include/core/SkSpinlock.h:24: error: undefined reference to 'SkPODSpinlock::contendedAcquire()'
collect2: error: ld returned 1 exit status
[mtklein added below here]
Despite the presence in include/ and the added SK_API, this file is not part of Skia's public API... it's just used by files which are.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1229003004
The proportion of time spent doing useful work is well over 99% in acquire(),
so outlining it doesn't hurt speed at all, and makes it much easier to pick out
on a profile.
It'd be about 50/50 work/overhead if we outlined the extremely-cheap release().
I also tried outlining some SkRefCnt methods with similar mixed results.
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1212253013
Follow up to the split between SkImageGenerator and SkCodec. Now that
SkCodec does not inherit from SkImageGenerator, SkImageGenerator no
longer needs Options or Result, which were added for SkCodec. Remove
them, but keep them behind a flag, since Chromium has its own
subclasses of SkImageGenerator which assume the old signature for
onGetPixels.
Review URL: https://codereview.chromium.org/1226023003
For some users of SkPictureRecorder, the cull rect is more efficiently
determined while drawing is in progress, rather than when recording starts.
The existing API requires the cull rect at start time, even though the
information is not used for any culling purpose until the end of recording.
This patch provides a means to reset the cull rect when recording ends,
allowing users to update the rect based on information learned during
drawing and for the new rect to be used as the culling bound. A valid
bound is still required on the beginRecording call because
it sizes the underlying canvas and sets the aspect ratio for any bounding
box hierarchy. The bounding box factory can also be specified and parameters
that control SkPicture creation.
R=mtklein, reed1
BUG=skia:3919
Review URL: https://codereview.chromium.org/1178673007
Some of this is transitive, like SkRecords.h used by SkMiniRecorder.h
used by (public) SkPictureRecorder.h.
BUG=skia:
Review URL: https://codereview.chromium.org/1217293004
This makes nanobench picture recording benchmarks somewhat useful again,
as opposed to all taking about 5us to run no matter the content.
ATTN Sheriff: this will probably trigger perf.skia.org alerts.
BUG=skia:
Review URL: https://codereview.chromium.org/1219873002
this also exposes nine-patch drawing directly to devices, and creates a shared iterator for unrolling a nine-patch into single rect->rect draws.
BUG=skia:
Review URL: https://codereview.chromium.org/1211583003
This CL continues cleaning up Skia's usage of SkSurfaceProps. It:
Removes the duplicate SkSurfaceProps object from SkImageFilter::Proxy.
Removes a dispreferred ctor from SkCanvas
Removes the initForRootLayer entry point from SkDevice (since the root device and the canvas should always have the same pixel geometry now).
Review URL: https://codereview.chromium.org/1201983006
This CL starts the process of pushing kLegacyFontHost_InitType-type SkSurfaceProps up the call stack and out of Skia. It:
Gets rid of the default SkBaseDevice ctor. This means everyone has to always hand an explicit SkSurfaceProps to it.
It makes public the SkBitmapDevice creation methods that require SkSurfaceProps.
Removes (in Skia's code base) all SkBitmapDevice ctor calls w/o SkSurfaceProps.
Makes the "recording" canvases (e.g., pdf, svg, xps) explicitly not use kLegacyFontHost_InitType.
Replicates the creating canvas/device's flags on saveLayer devices
BUG=skia:3934
Review URL: https://codereview.chromium.org/1204433002
sk_inv_determinant has a guard that the determinant can't get too big so this CL only checks if the determinant gets too small.
BUG=492263
Review URL: https://codereview.chromium.org/1188433011
This should be a drop-in replacement for most for-loops to make them run in parallel:
for (int i = 0; i < N; i++) { code... }
~~~>
sk_parallel_for(N, [&](int i) { code... });
This is just syntax sugar over SkTaskGroup to make this use case really easy to write.
There's no more overhead that we weren't already forced to add using an interface like batch(),
and no extra heap allocations.
I've replaced 3 uses of SkTaskGroup with sk_parallel_for:
1) My unit tests for SkOnce.
2) Cary's path fuzzer.
3) SkMultiPictureDraw.
Performance should be the same. Please compare left and right for readability. :)
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1184373003
- Use SkAtomic<int32_t> for pending work count so we're statically
forced to operate on it with atomic methods.
- Replacing old methods like sk_atomic_inc/dec gives us finer control
over which barriers we need for each operation.
No public API changes.
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1193493003
This fix is necessary to correctly propagate invalidations that
are external to skia. For example, when drawing video or WebGL
into a 2D canvas in Chrome, with mipmaps enabled.
BUG=crbug.com/498356
TEST=GrTextureMipMapInvalidationTest
Review URL: https://codereview.chromium.org/1177843007
- input param to addFoo (e.g. addRect), where only CW or CCW are valid)
- output param from computing functions, that sometimes return kUnknown
This CL's intent is to split these into distinct enums/features:
- Direction (public) loses kUnknown, and is only used for input
- FirstDirection (private) is used for computing the first direction we see when analyzing a contour
BUG=skia:
Review URL: https://codereview.chromium.org/1176953002
Tweak some test values to pass with floats.
As expected, this regresses matrix44_setconcat_general by about 2x.
BUG=skia:
Review URL: https://codereview.chromium.org/1169813006
Reason for revert:
gfx_unittests (under linux_asan)
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@Direct leak of 368 byte(s) in 1 object(s) allocated from:@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@ #0 0x4cc74b in __interceptor_malloc (/b/build/slave/linux_asan/build/src/out/Release/gfx_unittests+0x4cc74b)@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@ #1 0x7f2f7060ebdf in _cairo_image_surface_create_for_pixman_image /build/buildd/cairo-1.10.2/src/cairo-image-surface.c:158@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@Indirect leak of 256 byte(s) in 1 object(s) allocated from:@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@ #0 0x4cc74b in __interceptor_malloc (/b/build/slave/linux_asan/build/src/out/Release/gfx_unittests+0x4cc74b)@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@ #1 0x7f2f6c7be26a in _pixman_image_allocate /build/buildd/pixman-0.30.2/build/pixman/../../pixman/pixman-image.c:184@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@@@@
I think they are creating a cairo surface, but it has no pixels (zero size?). In this CL, if I see no pixels, I ignore the call-back which is used to free the surface (doh).
Original issue's description:
> Revert[4] of add asserts around results from requestLock
>
> This reverts commit 19663e54c0.
>
> BUG=skia:
> TBR=
>
> Committed: https://skia.googlesource.com/skia/+/df91b73a34e3a306c93a5e320704736255c3d9f0TBR=reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1151063005
Reason for revert:
asserts in ui/gfx unittests (need to investigate why)
[ RUN ] RenderTextTest.SelectionKeepsLigatures
[14602:14602:0529/134016:16779526944:INFO:SkPixelRef.cpp(164)] ../../third_party/skia/src/core/SkPixelRef.cpp:164: failed assertion "pixels"
Original issue's description:
> add asserts around results from requestLock and lockPixels, ensuring that true always means we have non-null pixels (and non-null colortable if that matches the colortype)
>
> BUG= 491975
> TBR=
>
> Committed: https://skia.googlesource.com/skia/+/f941a68126d8fe647eaea902c244c466568b7809TBR=scroggo@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 491975
Review URL: https://codereview.chromium.org/1159013006
This requires we "first" add a has-picture bool to SkPictureShader serialized format.
BUG=chromium:486947, billions and billions of others.
Review URL: https://codereview.chromium.org/1151663002
This re-enables adoption tracking for SkPictures in Blink,
which should be green now that crrev.com/1136123011 has landed.
BUG=skia:3847
Review URL: https://codereview.chromium.org/1145153002
Make the code more readable by inheriting GrStrokeInfo from SkStrokeRec.
This should avoid the long .getStrokeRec() and .getStrokeRecPtr(). These
were a bit cumbersome especially in cases where an alias variable was
created for these, and then the reader had to keep track to which
StrokeInfo member the StrokeRec alias was pointing.
Removes SkStrokeRec::SkStrokeRec(const SkStrokeRec&). It was memcpying.
Try to play it safe wrt compiler using the possible padding of
superclass for subclass members. Instead, let the compiler generate
the copy constructor. Assignment operator was already
compiler-generated, so at least in that way this is consistent.
Renames GrStrokeInfo::applyDash to applyDashToPath for consistency
with superclass applyToPath.
Review URL: https://codereview.chromium.org/1128113008
Reason for revert:
win_chromium_compile_dbg_ng
FAILED: ninja -t msvc -e environment.x86 -- E:\b\build\goma/gomacc "E:\b\depot_tools\win_toolchain\vs2013_files\VC\bin\amd64_x86\cl.exe" /nologo /showIncludes /FC @obj\third_party\skia\src\core\skia.SkBitmapHeap.obj.rsp /c ..\..\third_party\skia\src\core\SkBitmapHeap.cpp /Foobj\third_party\skia\src\core\skia.SkBitmapHeap.obj /Fdobj\skia\skia.cc.pdb
e:\b\build\slave\win\build\src\third_party\skia\include\core\skpicture.h(176) : error C2487: 'CURRENT_PICTURE_VERSION' : member of dll interface class may not be declared with dll interface
Original issue's description:
> Sketch splitting SkPicture into an interface and SkBigPicture.
>
> Adds small pictures for drawRect(), drawTextBlob(), and drawPath().
> These cover about 89% of draw calls from Blink SKPs,
> and about 25% of draw calls from our GMs.
>
> SkPicture handles:
> - serialization and deserialization
> - unique IDs
>
> Everything else is left to the subclasses:
> - playback(), cullRect()
> - hasBitmap(), hasText(), suitableForGPU(), etc.
> - LayerInfo / AccelData if applicable.
>
> The time to record a 1-op picture improves a good chunk
> (2 mallocs to 1), and the time to record a 0-op picture
> greatly improves (2 mallocs to none):
>
> picture_overhead_draw: 450ns -> 350ns
> picture_overhead_nodraw: 300ns -> 90ns
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/c92c129ff85b05a714bd1bf921c02d5e14651f8b
>
> Latest blink_linux_rel:
>
> http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/61248
>
> Committed: https://skia.googlesource.com/skia/+/15877b6eae33a9282458bdb904a6d00440eca0ecTBR=reed@google.com,robertphillips@google.com,fmalita@chromium.org,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1130283004
Adds small pictures for drawRect(), drawTextBlob(), and drawPath().
These cover about 89% of draw calls from Blink SKPs,
and about 25% of draw calls from our GMs.
SkPicture handles:
- serialization and deserialization
- unique IDs
Everything else is left to the subclasses:
- playback(), cullRect()
- hasBitmap(), hasText(), suitableForGPU(), etc.
- LayerInfo / AccelData if applicable.
The time to record a 1-op picture improves a good chunk
(2 mallocs to 1), and the time to record a 0-op picture
greatly improves (2 mallocs to none):
picture_overhead_draw: 450ns -> 350ns
picture_overhead_nodraw: 300ns -> 90ns
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/c92c129ff85b05a714bd1bf921c02d5e14651f8b
Latest blink_linux_rel:
http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/61248
Review URL: https://codereview.chromium.org/1112523006
Reason for revert:
Appears to be breaking Linux ARM bots:
FAILED:
/usr/local/google/home/mosaic-role/slave/repo_clients/chromium_tot/chromium/src/../../prebuilt/toolchain/armv7a/bin/armv7a-cros-linux-gnueabi-g++
... -o obj/third_party/skia/src/ports/skia_library.SkFontHost_FreeType.o
../../third_party/skia/src/ports/SkFontHost_FreeType.cpp:37:31: fatal error:
freetype/ftmm.h: No such file or directory
#include FT_MULTIPLE_MASTERS_H
^
compilation terminated.
Original issue's description:
> Font variations.
>
> Multiple Master and TrueType fonts support variation axes.
> This implements back-end support for axes on platforms which
> support it.
>
> Committed: https://skia.googlesource.com/skia/+/05773ed30920c0214d1433c07cf6360a05476c97
>
> Committed: https://skia.googlesource.com/skia/+/3489ee0f4fa34f124f9de090d12bdc2107d52aa9TBR=reed@google.com,mtklein@google.com,djsollen@google.com,halcanary@google.com,bungeman@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1139123008
I realized when writing the comment on https://crrev.com/1135363002/
that I'd really just sketched out the entire thing, so I couldn't help
but actually write up a working CL. How does this do for your benchmark?
BUG=chromium:487075
Review URL: https://codereview.chromium.org/1130123006
Implemented by extracting out the non-scale/translate components
and applying that post-filter as an SkMatrixImageFilter.
BUG=skia:
Review URL: https://codereview.chromium.org/1120043002
Multiple Master and TrueType fonts support variation axes.
This implements back-end support for axes on platforms which
support it.
Review URL: https://codereview.chromium.org/1027373002
Reason for revert:
speculative revert to fix failures in DEPS roll
Original issue's description:
> Sketch splitting SkPicture into an interface and SkBigPicture.
>
> Adds small pictures for drawRect(), drawTextBlob(), and drawPath().
> These cover about 89% of draw calls from Blink SKPs,
> and about 25% of draw calls from our GMs.
>
> SkPicture handles:
> - serialization and deserialization
> - unique IDs
>
> Everything else is left to the subclasses:
> - playback(), cullRect()
> - hasBitmap(), hasText(), suitableForGPU(), etc.
> - LayerInfo / AccelData if applicable.
>
> The time to record a 1-op picture improves a good chunk
> (2 mallocs to 1), and the time to record a 0-op picture
> greatly improves (2 mallocs to none):
>
> picture_overhead_draw: 450ns -> 350ns
> picture_overhead_nodraw: 300ns -> 90ns
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/c92c129ff85b05a714bd1bf921c02d5e14651f8bTBR=reed@google.com,robertphillips@google.com,mtklein@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1130333002
Adds small pictures for drawRect(), drawTextBlob(), and drawPath().
These cover about 89% of draw calls from Blink SKPs,
and about 25% of draw calls from our GMs.
SkPicture handles:
- serialization and deserialization
- unique IDs
Everything else is left to the subclasses:
- playback(), cullRect()
- hasBitmap(), hasText(), suitableForGPU(), etc.
- LayerInfo / AccelData if applicable.
The time to record a 1-op picture improves a good chunk
(2 mallocs to 1), and the time to record a 0-op picture
greatly improves (2 mallocs to none):
picture_overhead_draw: 450ns -> 350ns
picture_overhead_nodraw: 300ns -> 90ns
BUG=skia:
Review URL: https://codereview.chromium.org/1112523006
Motivation: PDF/A metadata will need the creation date embedded in it.
Also, GetDateTime returns local time in Win32. This now behaves the
same as on Unix systems.
BUG=skia:3110
Review URL: https://codereview.chromium.org/1109593002
All but 17 extended tests work.
A helper function is privately added to SkPath.h to permit a test to modify a given point in a path.
BUG=skia:3588
Review URL: https://codereview.chromium.org/1107353004
Must have been we needed them to be weird (mutable, const setter) before.
It doesn't look like that's necessary now... we can just pass it to the
constructor.
BUG=skia:
Review URL: https://codereview.chromium.org/1112833003
The pointer of reference is always not-null. It causes >50k lines of warnning when chromium is compiled by clang.
Warning looks like
../../third_party/skia/include/core/SkRect.h:284:19: warning: reference cannot be bound to dereferenced null pointer in well-defined C++ code; pointer may be assumed to always convert to true [-Wundefined-bool-conversion]
do { if (&r) break; SkNO_RETURN_HINT(); SkDebugf_FileLine("../../third_party/skia/include/core/SkRect.h", 284, false, "%s:%d: failed assertion \"%s\"\n", "../../third_party/skia/include/core/SkRect.h", 284, "&r"); SkDebugf_FileLine("../../third_party/skia/include/core/SkRect.h", 284, true, "SK_CRASH"); } while (false);
Review URL: https://codereview.chromium.org/1111013002
Reason for revert:
MIPS
Original issue's description:
> De-proc Color32
>
> Also strips SK_SUPPORT_LEGACY_COLOR32_MATH,
> which is no longer needed.
>
> Seems handy to have SkTypes include the relevant intrinsics when
> we know we've got them, but I'm not married to it.
>
> Locally this looks like a pointlessly small perf win, but I'm mostly
> keen to get all the code together.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/376e9bc206b69d9190f38dfebb132a8769bbd72bTBR=reed@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1108163002
Also strips SK_SUPPORT_LEGACY_COLOR32_MATH,
which is no longer needed.
Seems handy to have SkTypes include the relevant intrinsics when
we know we've got them, but I'm not married to it.
Locally this looks like a pointlessly small perf win, but I'm mostly
keen to get all the code together.
BUG=skia:
Review URL: https://codereview.chromium.org/1104183004
This may be a small help to slimming paint:
picture_overhead_draw 1.25us -> 1.22us 0.98x
picture_overhead_nodraw 318ns -> 276ns 0.87x
It certainly cannot hurt performance.
BUG=chromium:470553
TBR=reed@google.com
No public API changes.
Review URL: https://codereview.chromium.org/1098183003
This saves "up to" 22 bytes per SkPicture.
Due to alignment, this reduces sizeof(SkPicture):
- from 88 to 72 bytes on Linux x64
- from 68 to 48 bytes on Android
(with Chrome's build settings)
It also somewhat simplifies the GPU veto logic.
BUG=skia:
[mtklein] No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1060863004
Chrome wants to call this more often, and it's quite slow today.
Seems like this could be clearer if SkPictureUtils::ApproxBytesUsed() were SkPicture::approxBytesUsed().
BUG=chromium:471873
Review URL: https://codereview.chromium.org/1090943004
SkFixedToDouble uses the decimal floating point string representation
of 1/(2^16) to provide a constant value. This value is exactly
representable by a double but the decimal constant currently used
does not map to this value.
This change modifies this constant to more decimal digits so that
the actual double value desired is created.
Review URL: https://codereview.chromium.org/1097473002
Currently there exist SkScalarPin and SkPin32, and in a future change
another version is desired. This change introduces SkTPin and changes
SkScalarPin and SkPin32 to use it.
Review URL: https://codereview.chromium.org/1090003002
The benches for N <= 10 get around 2x faster on my N7 and N9. I believe this
is because of the reduced function-call-then-function-pointer-call overhead on
the N7, and additionally because it seems autovectorization beats our NEON code
for small N on the N9.
My desktop is unchanged, though that's probably because N=10 lies well within a
region where memset's performance is essentially constant: N=100 takes only
about 2x as long as N=1 and N=10, which perform nearly identically.
BUG=skia:
Review URL: https://codereview.chromium.org/1073863002
Instead of using a full-blown SkPaint to store run font info, use a
custom structure.
This saves 96 bytes / run on 64bit platforms.
R=reed@google.com,mtklein@google.com,joshualitt@google.com
Review URL: https://codereview.chromium.org/1070943002
No diffs against head for DM --config 8888 gpu 2ndpic-8888 2ndpic-gpu.
picture_overhead_draw 1.62us -> 1.6us 0.99x
picture_overhead_nodraw 792ns -> 342ns 0.43x
tiles and serialization modes will also test this a bit.
BUG=chromium:470553
Review URL: https://codereview.chromium.org/1067893002
If no one has read the picture's unique ID, there's no point invalidating it.
This is the same trick we pull with SkPixelRefs.
Before:
26M 1 1.49µs 1.6µs 1.77µs 6.25µs 42% picture_overhead_draw
13M 32 742ns 749ns 756ns 823ns 2% picture_overhead_nodraw
After:
26M 1 1.27µs 1.33µs 1.49µs 5.51µs 45% picture_overhead_draw
14M 43 677ns 680ns 681ns 701ns 1% picture_overhead_nodraw
BUG=skia:
Review URL: https://codereview.chromium.org/1061283002
- It's no longer needed to help the (2011?) transition to SkAutoTUnref.
- It prevents us from making classes that go in SkAutoTUnrefs final,
i.e. all ref-counted classes.
This had better not have been public API...
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1068443002
Add a virtual method on SkStream which will do a "peek" some bytes, so
that those bytes are read, but the next call to read will be
unaffected.
Implement peek for SkMemoryStream, where the implementation is simple
and obvious.
Implement peek on SkFrontBufferedStream.
Add tests.
Motivated by decoding streams which cannot be rewound.
TBR=reed@google.com
BUG=skia:3257
Review URL: https://codereview.chromium.org/1044953002
