Raster into an SkP before rendering a DisplayList.

Raster into an SkPicture before rendering a DisplayList.

Rasterizing a display list is more than 2x slower than rasterizing in the existing architecture. This is due to recording more with a display list and we have no bounding hierarchy to cull content quickly.

We can address this by creating an SkPicture from the list, with a bounding hierarchy, and rasterizing that instead. The result is slightly faster than the non-S.P. pipeline but uses 2x more memory.

BUG=464738
Committed: https://crrev.com/de765f47e9449420e46d968ec40bb6f41a193990
Cr-Commit-Position: refs/heads/master@{#319519}

Committed: https://crrev.com/c54bea7972a4a26fe49fd43a07cc99bb3a0e1990
Cr-Commit-Position: refs/heads/master@{#320097}

[Stephen Chennney, 2015-03-06 16:43:05]

schenney@chromium.org changed reviewers:
+ ajuma@chromium.org, enne@chromium.org

[Stephen Chennney, 2015-03-06 16:43:36]

Chris and I decided this is the best approach to speed up raster for now.

[ajuma, 2015-03-06 17:02:11]

https://codereview.chromium.org/966443003/diff/20001/cc/resources/display_lis...
File cc/resources/display_list_recording_source.cc (right):

https://codereview.chromium.org/966443003/diff/20001/cc/resources/display_lis...
cc/resources/display_list_recording_source.cc:116:
display_list_->CreateAndCacheSkPicture();
Should we repeat too this when repeating PaintContentsToDisplayList above, so
that the cost of this caching is correctly factored into record time
measurements?

[Stephen Chennney, 2015-03-06 17:51:11]

https://codereview.chromium.org/966443003/diff/20001/cc/resources/display_lis...
File cc/resources/display_list_recording_source.cc (right):

https://codereview.chromium.org/966443003/diff/20001/cc/resources/display_lis...
cc/resources/display_list_recording_source.cc:116:
display_list_->CreateAndCacheSkPicture();
On 2015/03/06 17:02:11, ajuma wrote:
> Should we repeat too this when repeating PaintContentsToDisplayList above, so
> that the cost of this caching is correctly factored into record time
> measurements?

The loop above is only for debug rendering slowdown. It's not the method used to
repeat for record time measurements; that call this entire method repeatedly. So
I think we're fine here.

[ajuma, 2015-03-06 17:54:23]

On 2015/03/06 17:51:11, Stephen Chenney wrote:
>
https://codereview.chromium.org/966443003/diff/20001/cc/resources/display_lis...
> File cc/resources/display_list_recording_source.cc (right):
> 
>
https://codereview.chromium.org/966443003/diff/20001/cc/resources/display_lis...
> cc/resources/display_list_recording_source.cc:116:
> display_list_->CreateAndCacheSkPicture();
> On 2015/03/06 17:02:11, ajuma wrote:
> > Should we repeat too this when repeating PaintContentsToDisplayList above,
so
> > that the cost of this caching is correctly factored into record time
> > measurements?
> 
> The loop above is only for debug rendering slowdown. It's not the method used
to
> repeat for record time measurements; that call this entire method repeatedly.
So
> I think we're fine here.

lgtm

[Stephen Chennney, 2015-03-06 17:57:11]

The CQ bit was checked by schenney@chromium.org

[commit-bot: I haz the power, 2015-03-06 17:58:11]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/966443003/20001

[commit-bot: I haz the power, 2015-03-06 22:59:23]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-03-06 23:00:08]

Patchset 2 (id:??) landed as
https://crrev.com/de765f47e9449420e46d968ec40bb6f41a193990
Cr-Commit-Position: refs/heads/master@{#319519}

[chrishtr, 2015-03-06 23:36:06]

On 2015/03/06 at 23:00:08, commit-bot wrote:
> Patchset 2 (id:??) landed as
https://crrev.com/de765f47e9449420e46d968ec40bb6f41a193990
> Cr-Commit-Position: refs/heads/master@{#319519}

This broke some layout tests, in particular the ones referred to in
crbug.com/460198. Reverting.

[chrishtr, 2015-03-06 23:36:24]

A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/980793007/revert by chrishtr@chromium.org.

The reason for reverting is: This broke some layout tests, in particular the
ones referred to in crbug.com/460198..

[Stephen Chennney, 2015-03-09 21:16:04]

Expectations are in the Blonk CQ. Will re-land once they are committed and
rolled into Chromium.

[Stephen Chennney, 2015-03-11 14:20:19]

The CQ bit was checked by schenney@chromium.org

[commit-bot: I haz the power, 2015-03-11 14:20:56]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/966443003/20001

[commit-bot: I haz the power, 2015-03-11 17:03:16]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-03-11 17:03:51]

Patchset 2 (id:??) landed as
https://crrev.com/c54bea7972a4a26fe49fd43a07cc99bb3a0e1990
Cr-Commit-Position: refs/heads/master@{#320097}

[adamk, 2015-03-11 18:48:45]

A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/997173003/ by adamk@chromium.org.

The reason for reverting is: Fails several slimmingpaint layout tests on Linux

Failures that look to be real bugs include:

 
virtual/slimmingpaint/fast/table/border-collapsing/adjacent-row-groups-multi.html
  virtual/slimmingpaint/fast/text/emphasis.html.

[adamk, 2015-03-11 18:49:53]

In future, please open a new Rietveld issue instead of landing multiple changes
from the same issue; this helps avoid confusion and bloat in the commit log.