SkLite*

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

Committed: https://skia.googlesource.com/skia/+/9c5052f16b249d2b7674ea86bd24ed0038ccc61f

[mtklein_C, 2016-08-05 02:10:58]

Description was changed from

==========
SkLitePic

BUG=skia:
==========

to

==========
SkLitePic

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
==========

[mtklein_C, 2016-08-05 17:50:09]

Description was changed from

==========
SkLitePic

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
==========

to

==========
SkLite*

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
==========

[mtklein, 2016-08-05 19:55:47]

Description was changed from

==========
SkLite*

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
==========

to

==========
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 for Android:

  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 2x faster at various size pictures,
including pictures with 0 or 1 draws that we've special cased today.  (We won't
need those special cases anymore.)

It's 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, but
it's 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.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
==========

[mtklein, 2016-08-05 19:56:13]

Description was changed from

==========
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 for Android:

  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 2x faster at various size pictures,
including pictures with 0 or 1 draws that we've special cased today.  (We won't
need those special cases anymore.)

It's 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, but
it's 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.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
==========

to

==========
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 2x faster at various size pictures,
including pictures with 0 or 1 draws that we've special cased today.  (We won't
need those special cases anymore.)

It's 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, but
it's 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.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
==========

[mtklein, 2016-08-05 19:56:52]

Description was changed from

==========
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 2x faster at various size pictures,
including pictures with 0 or 1 draws that we've special cased today.  (We won't
need those special cases anymore.)

It's 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, but
it's 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.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
==========

to

==========
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 2x faster at various size pictures,
including pictures with 0 or 1 draws that we've special cased today.  (We won't
need those special cases anymore.)

It's 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, but
it's 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.

It should be simple to wrap this into an SkPicture subclass if we want.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
==========

[mtklein, 2016-08-05 19:57:39]

Description was changed from

==========
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 2x faster at various size pictures,
including pictures with 0 or 1 draws that we've special cased today.  (We won't
need those special cases anymore.)

It's 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, but
it's 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.

It should be simple to wrap this into an SkPicture subclass if we want.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
==========

to

==========
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 2x faster at various size pictures,
including pictures with 0 or 1 draws that we've special cased today.  (We won't
need those special cases anymore.)

It's 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, but
it's 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.  I have not yet compared playback performance.

It should be simple to wrap this into an SkPicture subclass if we want.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
==========

[mtklein, 2016-08-05 20:06:14]

Description was changed from

==========
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 2x faster at various size pictures,
including pictures with 0 or 1 draws that we've special cased today.  (We won't
need those special cases anymore.)

It's 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, but
it's 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.  I have not yet compared playback performance.

It should be simple to wrap this into an SkPicture subclass if we want.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
==========

to

==========
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 2x faster at various size pictures,
including pictures with 0 or 1 draws that we've special cased today.  (We won't
need those special cases anymore.)

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.

It's 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 it's 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.  I have not yet compared playback performance.

It should be simple to wrap this into an SkPicture subclass if we want.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
==========

[mtklein, 2016-08-05 20:11:37]

Description was changed from

==========
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 2x faster at various size pictures,
including pictures with 0 or 1 draws that we've special cased today.  (We won't
need those special cases anymore.)

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.

It's 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 it's 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.  I have not yet compared playback performance.

It should be simple to wrap this into an SkPicture subclass if we want.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
==========

to

==========
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 2x faster for various size pictures,
including for pictures with 0 or 1 draws that we've special cased today.  (I.e.
we won't need those special case implementations anymore, because they're slower
than this new generic code.)

This strategy stays the winner up to about 300 drawRect()s on my laptop, where I
think we're either hitting my arbitrary freelisting size limit or the chunk
allocation strategy of SkRecord finally starts to pay off.

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 it's 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.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
==========

[mtklein, 2016-08-05 20:13:34]

Description was changed from

==========
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 2x faster for various size pictures,
including for pictures with 0 or 1 draws that we've special cased today.  (I.e.
we won't need those special case implementations anymore, because they're slower
than this new generic code.)

This strategy stays the winner up to about 300 drawRect()s on my laptop, where I
think we're either hitting my arbitrary freelisting size limit or the chunk
allocation strategy of SkRecord finally starts to pay off.

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 it's 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.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
==========

to

==========
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 2x faster for various size pictures,
including for pictures with 0 or 1 draws that we've special cased today.  (I.e.
we won't need those special case implementations anymore, because they're slower
than this new generic code.)

This strategy stays the winner up to about 300 drawRect()s on my laptop, where I
think we're either hitting my arbitrary freelisting size limit or the chunk
allocation strategy of SkRecord finally starts to pay off.

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 it's 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
==========

[mtklein_C, 2016-08-05 20:17:40]

mtklein@chromium.org changed reviewers:
+ djsollen@google.com, reed@google.com

[mtklein_C, 2016-08-05 20:19:16]

Description was changed from

==========
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 2x faster for various size pictures,
including for pictures with 0 or 1 draws that we've special cased today.  (I.e.
we won't need those special case implementations anymore, because they're slower
than this new generic code.)

This strategy stays the winner up to about 300 drawRect()s on my laptop, where I
think we're either hitting my arbitrary freelisting size limit or the chunk
allocation strategy of SkRecord finally starts to pay off.

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 it's 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
==========

to

==========
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 2x faster for 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 strategy stays the winner up to about 300 drawRect()s on my laptop, where I
think we're either hitting my arbitrary freelisting size limit or the chunk
allocation strategy of SkRecord finally starts to pay off.

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 it's 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
==========

[mtklein_C, 2016-08-05 20:20:33]

Description was changed from

==========
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 2x faster for 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 strategy stays the winner up to about 300 drawRect()s on my laptop, where I
think we're either hitting my arbitrary freelisting size limit or the chunk
allocation strategy of SkRecord finally starts to pay off.

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 it's 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
==========

to

==========
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 2x faster for 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 strategy stays the winner up to about 300 drawRect()s on my laptop, where I
think we're either hitting my arbitrary freelisting size limit or the chunk
allocation strategy of SkRecord finally starts to pay off.

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
==========

[mtklein_C, 2016-08-05 20:51:07]

Description was changed from

==========
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 2x faster for 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 strategy stays the winner up to about 300 drawRect()s on my laptop, where I
think we're either hitting my arbitrary freelisting size limit or the chunk
allocation strategy of SkRecord finally starts to pay off.

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
==========

to

==========
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
==========

[mtklein_C, 2016-08-05 20:53:45]

Just a quick update in case you have already started reading.  I just updated
the performance summary after fixing a lazy bit of coding (SkPaint instead of
const SkPaint&...).  The speedup goes from ~2x to ~3x for smallish pictures, and
it's faster up until at least 500 drawRects(), where I stopped checking.  So,
even faster, less ambiguously so.

[mtklein_C, 2016-08-05 21:13:26]

The CQ bit was checked by mtklein@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-05 21:13:37]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[reed1, 2016-08-05 22:01:08]

seems very easy to read. lgtm esp. since it doesn't affect any other code-flow
(so very little risk).

Using SkTDArray, which will just memmove/memcpy when it has to grow. Very fast,
but I guess we have to know that none of our stored classes (e.g. SkPaint,
SkPath, etc.) will be adversely affected by that (e.g. have no self-pointers)...

[mtklein, 2016-08-05 22:08:00]

> Using SkTDArray, which will just memmove/memcpy when it has to grow. Very
fast,
> but I guess we have to know that none of our stored classes (e.g. SkPaint,
> SkPath, etc.) will be adversely affected by that (e.g. have no
self-pointers)...

In fact it grows with realloc, which is potentially even faster (but basically
worst-case memcpy, yeah).

Correct about the new constraint though... the types we placement new will have
to be relocatable.  So far I think that's all true.  We'll see if this turns out
to be a tricky constraint to work around...

[mtklein, 2016-08-05 22:12:27]

The CQ bit was unchecked by mtklein@google.com

[mtklein, 2016-08-05 22:12:32]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2016-08-05 22:12:36]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[mtklein, 2016-08-05 23:14:27]

The CQ bit was unchecked by mtklein@google.com

[mtklein_C, 2016-08-06 19:17:16]

The CQ bit was checked by mtklein@chromium.org

[mtklein_C, 2016-08-06 19:17:17]

The patchset sent to the CQ was uploaded after l-g-t-m from reed@google.com
Link to the patchset: https://codereview.chromium.org/2213333002/#ps330001
(title: "fix include")

[commit-bot: I haz the power, 2016-08-06 19:17:28]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-06 19:24:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-06 19:24:58]

Try jobs failed on following builders:
  Build-Win-MSVC-x86_64-Debug-Trybot on master.client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Win-MSVC-x86_6...)

[mtklein_C, 2016-08-06 19:30:21]

The CQ bit was checked by mtklein@chromium.org

[mtklein_C, 2016-08-06 19:30:22]

The patchset sent to the CQ was uploaded after l-g-t-m from reed@google.com
Link to the patchset: https://codereview.chromium.org/2213333002/#ps350001
(title: "annoying...")

[commit-bot: I haz the power, 2016-08-06 19:30:29]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-06 19:51:56]

Description was changed from

==========
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
==========

to

==========
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

Committed:
https://skia.googlesource.com/skia/+/9c5052f16b249d2b7674ea86bd24ed0038ccc61f
==========

[commit-bot: I haz the power, 2016-08-06 19:52:00]

Committed patchset #19 (id:350001) as
https://skia.googlesource.com/skia/+/9c5052f16b249d2b7674ea86bd24ed0038ccc61f