SkLite*
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
2016-08-06 19:51:51 +00:00
|
|
|
/*
|
|
|
|
|
* Copyright 2016 Google Inc.
|
|
|
|
|
*
|
|
|
|
|
* Use of this source code is governed by a BSD-style license that can be
|
|
|
|
|
* found in the LICENSE file.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef SkLiteRecorder_DEFINED
|
|
|
|
|
#define SkLiteRecorder_DEFINED
|
|
|
|
|
|
|
|
|
|
#include "SkCanvas.h"
|
|
|
|
|
|
|
|
|
|
class SkLiteDL;
|
|
|
|
|
|
|
|
|
|
class SkLiteRecorder final : public SkCanvas {
|
|
|
|
|
public:
|
|
|
|
|
SkLiteRecorder();
|
|
|
|
|
void reset(SkLiteDL*);
|
|
|
|
|
|
|
|
|
|
sk_sp<SkSurface> onNewSurface(const SkImageInfo&, const SkSurfaceProps&) override;
|
|
|
|
|
|
|
|
|
|
void willSave() override;
|
|
|
|
|
SaveLayerStrategy getSaveLayerStrategy(const SaveLayerRec&) override;
|
|
|
|
|
void willRestore() override;
|
|
|
|
|
|
|
|
|
|
void didConcat(const SkMatrix&) override;
|
|
|
|
|
void didSetMatrix(const SkMatrix&) override;
|
2016-08-19 16:05:27 +00:00
|
|
|
void didTranslate(SkScalar, SkScalar) override;
|
SkLite*
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
2016-08-06 19:51:51 +00:00
|
|
|
|
|
|
|
|
void onClipRect (const SkRect&, SkRegion::Op, ClipEdgeStyle) override;
|
|
|
|
|
void onClipRRect (const SkRRect&, SkRegion::Op, ClipEdgeStyle) override;
|
|
|
|
|
void onClipPath (const SkPath&, SkRegion::Op, ClipEdgeStyle) override;
|
|
|
|
|
void onClipRegion(const SkRegion&, SkRegion::Op) override;
|
|
|
|
|
|
|
|
|
|
void onDrawPaint (const SkPaint&) override;
|
|
|
|
|
void onDrawPath (const SkPath&, const SkPaint&) override;
|
|
|
|
|
void onDrawRect (const SkRect&, const SkPaint&) override;
|
|
|
|
|
void onDrawOval (const SkRect&, const SkPaint&) override;
|
2016-08-19 18:25:19 +00:00
|
|
|
void onDrawArc(const SkRect&, SkScalar, SkScalar, bool, const SkPaint&) override;
|
SkLite*
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
2016-08-06 19:51:51 +00:00
|
|
|
void onDrawRRect (const SkRRect&, const SkPaint&) override;
|
|
|
|
|
void onDrawDRRect(const SkRRect&, const SkRRect&, const SkPaint&) override;
|
|
|
|
|
|
|
|
|
|
void onDrawDrawable(SkDrawable*, const SkMatrix*) override;
|
|
|
|
|
void onDrawPicture(const SkPicture*, const SkMatrix*, const SkPaint*) override;
|
|
|
|
|
void onDrawAnnotation(const SkRect&, const char[], SkData*) override;
|
|
|
|
|
|
|
|
|
|
void onDrawText (const void*, size_t, SkScalar x, SkScalar y, const SkPaint&) override;
|
|
|
|
|
void onDrawPosText (const void*, size_t, const SkPoint[], const SkPaint&) override;
|
|
|
|
|
void onDrawPosTextH (const void*, size_t, const SkScalar[], SkScalar, const SkPaint&) override;
|
|
|
|
|
void onDrawTextOnPath(const void*, size_t,
|
|
|
|
|
const SkPath&, const SkMatrix*, const SkPaint&) override;
|
|
|
|
|
void onDrawTextRSXform(const void*, size_t,
|
|
|
|
|
const SkRSXform[], const SkRect*, const SkPaint&) override;
|
|
|
|
|
void onDrawTextBlob(const SkTextBlob*, SkScalar, SkScalar, const SkPaint&) override;
|
|
|
|
|
|
|
|
|
|
void onDrawBitmap(const SkBitmap&, SkScalar, SkScalar, const SkPaint*) override;
|
2016-08-16 16:31:08 +00:00
|
|
|
void onDrawBitmapLattice(const SkBitmap&, const Lattice&, const SkRect&,
|
|
|
|
|
const SkPaint*) override;
|
SkLite*
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
2016-08-06 19:51:51 +00:00
|
|
|
void onDrawBitmapNine(const SkBitmap&, const SkIRect&, const SkRect&, const SkPaint*) override;
|
|
|
|
|
void onDrawBitmapRect(const SkBitmap&, const SkRect*, const SkRect&, const SkPaint*,
|
|
|
|
|
SrcRectConstraint) override;
|
|
|
|
|
|
|
|
|
|
void onDrawImage(const SkImage*, SkScalar, SkScalar, const SkPaint*) override;
|
|
|
|
|
void onDrawImageLattice(const SkImage*, const Lattice&, const SkRect&, const SkPaint*) override;
|
|
|
|
|
void onDrawImageNine(const SkImage*, const SkIRect&, const SkRect&, const SkPaint*) override;
|
|
|
|
|
void onDrawImageRect(const SkImage*, const SkRect*, const SkRect&, const SkPaint*,
|
|
|
|
|
SrcRectConstraint) override;
|
|
|
|
|
|
|
|
|
|
void onDrawPatch(const SkPoint[12], const SkColor[4],
|
|
|
|
|
const SkPoint[4], SkXfermode*, const SkPaint&) override;
|
|
|
|
|
void onDrawPoints(PointMode, size_t count, const SkPoint pts[], const SkPaint&) override;
|
|
|
|
|
void onDrawVertices(VertexMode, int, const SkPoint[], const SkPoint[], const SkColor[],
|
|
|
|
|
SkXfermode*, const uint16_t[], int, const SkPaint&) override;
|
|
|
|
|
void onDrawAtlas(const SkImage*, const SkRSXform[], const SkRect[], const SkColor[],
|
|
|
|
|
int, SkXfermode::Mode, const SkRect*, const SkPaint*) override;
|
|
|
|
|
|
|
|
|
|
#ifdef SK_EXPERIMENTAL_SHADOWING
|
|
|
|
|
void didTranslateZ(SkScalar) override;
|
2016-08-25 13:30:23 +00:00
|
|
|
void onDrawShadowedPicture(const SkPicture*, const SkMatrix*,
|
|
|
|
|
const SkPaint*, const SkShadowParams& params) override;
|
SkLite*
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
2016-08-06 19:51:51 +00:00
|
|
|
#else
|
|
|
|
|
void didTranslateZ(SkScalar);
|
2016-08-25 13:30:23 +00:00
|
|
|
void onDrawShadowedPicture(const SkPicture*, const SkMatrix*,
|
|
|
|
|
const SkPaint*, const SkShadowParams& params);
|
SkLite*
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
2016-08-06 19:51:51 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
SkLiteDL* fDL;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#endif//SkLiteRecorder_DEFINED
|
