- This code is entirely private and is not being used by anything.
- In a future CL we will write a class that uses CurveMeasure to compute dash points. In order to determine whether CurveMeasure or PathMeasure should be faster, we need the dash info (the sum of the on/off intervals and how many there are)
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2187083002
Review-Url: https://codereview.chromium.org/2187083002
This simply caps the number of times a display list can be reused.
As this number goes up, the average amount of memory we cache goes up
and the expected number of mallocs per SkLiteDL::New() goes down.
This strategy does not need a hard-coded cap on how many display lists
to cache, or how big they can grow.
TBR=herb@google.com
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2226813002
Review-Url: https://codereview.chromium.org/2226813002
The main feature is <svg> viewBox and proper viewport support, but the CL
touches a few other things:
* refactor SkSVGRenderContext to auto-restore canvas state, and split the
presentation bits into a separate CoW SkSVGPresentationContext
* introduce SkSVGNode::onPrepareToRender(), as a way for nodes to push their
custom state before the actual onRender() call (instead of relying on
non-virtual SkSVGNode to know about all possible state bits)
* add a "Type" suffix to SVG types, to disambiguate (e.g. SkSVGRectType vs.
SkSVGRect)
R=robertphillips@google.com,stephana@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2222793002
Review-Url: https://codereview.chromium.org/2222793002
About 9x faster than Murmur3 for long inputs.
Most of this is a mechanical change from SkChecksum::Murmur3(...) to SkOpts::hash(...).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2208903002
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot;master.client.skia.compile:Build-Ubuntu-GCC-x86_64-Release-CMake-Trybot,Build-Mac-Clang-x86_64-Release-CMake-Trybot
Review-Url: https://codereview.chromium.org/2208903002
The code protected by this flag is no longer used. Remove the flag and
code. This also removes SK_SUPPORT_LEGACY_TYPEFACE_PTR from Android, as
it is no longer needed.
TBR=reed
Only removes already guarded API.
Review-Url: https://codereview.chromium.org/2223933002
SkLiteRecorder, a new SkCanvas, fills out SkLiteDL, a new SkDrawable.
This SkDrawable is a display list similar to SkRecord and SkBigPicture / SkRecordedDrawable, but with a few new design points inspired by Android and slimming paint:
1) SkLiteDL is structured as one big contiguous array rather than the two layer structure of SkRecord. This trades away flexibility and large-op-count performance for better data locality for small to medium size pictures.
2) We keep a global freelist of SkLiteDLs, both reusing the SkLiteDL struct itself and its contiguous byte array. This keeps the expected number of mallocs per display list allocation <1 (really, ~0) for cyclical use cases.
These two together mean recording is faster. Measuring against the code we use at head, SkLiteRecorder trends about ~3x faster across various size pictures, matching speed at 0 draws and beating the special-case 1-draw pictures we have today. (I.e. we won't need those special case implementations anymore, because they're slower than this new generic code.) This new strategy records 10 drawRects() in about the same time the old strategy took for 2.
This strategy stays the winner until at least 500 drawRect()s on my laptop, where I stopped checking.
A simpler alternative to freelisting is also possible (but not implemented here), where we allow the client to manually reset() an SkLiteDL for reuse when its refcnt is 1. That's essentially what we're doing with the freelist, except tracking what's available for reuse globally instead of making the client do it.
This code is not fully capable yet, but most of the key design points are there. The internal structure of SkLiteDL is the area I expect to be most volatile (anything involving Op), but its interface and the whole of SkLiteRecorder ought to be just about done.
You can run nanobench --match picture_overhead as a demo. Everything it exercises is fully fleshed out, so what it tests is an apples-to-apples comparison as far as recording costs go. I have not yet compared playback performance.
It should be simple to wrap this into an SkPicture subclass if we want.
I won't start proposing we replace anything old with anything new quite yet until I have more ducks in a row, but this does look pretty promising (similar to the SkRecord over old SkPicture change a couple years ago) and I'd like to land, experiment, iterate, especially with an eye toward Android.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
Review-Url: https://codereview.chromium.org/2213333002
SkPDFFont:
- never request kHAdvance_PerGlyphInfo from typeface.
- set_glyph_widths() fn uses a glyph cache to get advances.
- stop expecting vertical advances that are never requested.
- composeAdvanceData() now non-templated
- appendAdvance() one-line function removed
SkPDFDevice:
- use a glyph cache for getting repeated advances.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2219733004
Review-Url: https://codereview.chromium.org/2219733004
In Firefox, we use SkCanvas::saveLayer in combination with a backdrop that initializes the layer to the background. When this is blended back onto background using transparency, where the source and destination pixel colors are the same, the resulting color after the blend is not preserved due to the lost precision mentioned above. In cases where this operation is repeatedly performed, this causes substantially noticeable differences in color as evidenced in this downstream Firefox bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1200684
In the test-case in the downstream report, essentially it does blend(src=0xFF2E3338, dst=0xFF2E3338, scale=217), which gives the result 0xFF2E3237, while we would expect to get back 0xFF2E3338.
This problem goes away if the blend is instead reformulated to effectively do (src*src_scale + dst*dst_scale)>>8, which keeps the intermediate precision during the addition before shifting it off.
This modifies the blending operations thusly. The performance should remain mostly unchanged, or possibly improve slightly, so there should be no real downside to doing this, with the benefit of making the results more accurate. Without this, it is currently unsafe for Firefox to blend a layer back onto itself that was initialized with a copy of its background.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2097883002
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
[mtklein adds...]
No public API changes.
TBR=reed@google.com
Review-Url: https://codereview.chromium.org/2097883002
Change SkDataTable::NewXXX to SkDataTable::MakeXXX and return sk_sp.
This updates users of SkDataTable to sk_sp as well.
There do not appear to be any external users of these methods.
Review-Url: https://codereview.chromium.org/2211143002
