Back PaintRecord with PaintOpBuffer instead of SkPicture
Change the backing of PaintRecord to be a data structure implemented in
cc/paint instead of using SkPicture directly. This new class cribs heavily
from SkLiteDL.
PaintRecord used to be a typedef to an SkPicture but now is a typedef to
a PaintOpBuffer. (This leaves some flexibility to change this in the
future to an interface without having to modify all of Chromium again.)
PaintOpBuffer stores a contiguous array of ops, with the ops stored
in place. As an optimization, the first op is stored locally in the
PaintOpBuffer itself to avoid extra allocations for small pictures.
This patch moves slow path counting from a gpu analysis canvas into
PaintOpBuffer directly. As ops are recorded, slow paths are counted, and
a PaintRecord now knows how many ops it has. This is about a 1.5% savings
for record time (gpu analysis was 2% and 0.5% overhead to record later).
This patch also implements the SkRecordNoopSaveLayerDrawRestores
optimization from Skia at raster time. This takes save layer (just
opacity) / draw / restore commands and turns them into draws with
opacity. It moves that optimization from Blink at record time inside of
CompositingRecorder and moves it to both DisplayItemList::RasterItem
and PaintOpBuffer::playback (since a save could be either a DisplayItem
or a PaintOp). It's not as robust as Skia's solution and so misses
a few cases that Skia catches, but the rasterize and record on 10k
page agreed that performance was good enough.
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Review-Url: https://codereview.chromium.org/2768143002
Cr-Commit-Position: refs/heads/master@{#468548}
71 files changed