| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will allow us to optimize for the RectGrid macrobench.
Currently, SkiaGL is much slower than OpenGL.
SkiaGL 12 items/s
OpenGL 160 items/s
This contains everything except for the fast implementation on GPU.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2277053002
Review-Url: https://codereview.chromium.org/2277053002
|
| |
|
|
|
|
|
| |
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2224163005
Review-Url: https://codereview.chromium.org/2224163005
|
| |
|
|
|
|
|
|
|
| |
Plumbs the drawArc canvas method down to SkDevice without converting to a path. Plumbs through the various recording canvas classes.
BUG=skia:5227
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2257023003
Review-Url: https://codereview.chromium.org/2257023003
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds didTranslate() so that SkLiteDL (and other canvas recorders)
can record the translate rather than the full concat.
It also adds a case to SkMatrix::preTranslate() to fast path
translate x translate -> translate (i.e. +=).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2255283002
Committed: https://skia.googlesource.com/skia/+/5fa47f4fd13b3158de4599414c86d17649c2dd1c
Misc bots failing in pictureimagefilter replay modes.
https://luci-milo.appspot.com/swarming/task/30b8e53f3a1f4f10/steps/dm/0/stdout
Problem is FMA vs. not.
CQ_INCLUDE_TRYBOTS=master.client.skia:
Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-Fast-Trybot
Review-Url: https://codereview.chromium.org/2255283002
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
id:80001 of https://codereview.chromium.org/2255283002/ )
Reason for revert:
speculative
Original issue's description:
> Fast path translate() in SkCanvas and SkLiteDL.
>
> This adds didTranslate() so that SkLiteDL (and other canvas recorders)
> can record the translate rather than the full concat.
>
> It also adds a case to SkMatrix::preTranslate() to fast path
> translate x translate -> translate (i.e. +=).
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2255283002
>
> Committed: https://skia.googlesource.com/skia/+/5fa47f4fd13b3158de4599414c86d17649c2dd1c
TBR=herb@google.com,reed@google.com,mtklein@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review-Url: https://codereview.chromium.org/2264433002
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This adds didTranslate() so that SkLiteDL (and other canvas recorders)
can record the translate rather than the full concat.
It also adds a case to SkMatrix::preTranslate() to fast path
translate x translate -> translate (i.e. +=).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2255283002
Review-Url: https://codereview.chromium.org/2255283002
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
out/Release/nanobench --match Lattice --config gpu --ms 3000
3.42ms -> 17.2us
For reference, a loop over drawBitmapRects (which is what
Android currently does) is about 13us.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2205273003
Review-Url: https://codereview.chromium.org/2205273003
|
|
|
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
|
msarett
vjiaoblack
bsalomon
mtklein
mtklein