Use the skmultipicture to perform GPU rasterization

cc/resources/picture.cc

 // Copyright 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "cc/resources/picture.h"
 
 #include <algorithm>
 #include <limits>
 #include <set>
 
@@ skipping 332 matching lines @@
 
   canvas->save();
 
   for (Region::Iterator it(negated_content_region); it.has_rect(); it.next())
     canvas->clipRect(gfx::RectToSkRect(it.rect()), SkRegion::kDifference_Op);
 
   canvas->scale(contents_scale, contents_scale);
   canvas->translate(layer_rect_.x(), layer_rect_.y());
   if (playback_) {
     playback_->draw(canvas);
+  } else if (callback) {
+    picture_->draw(canvas, callback);  // AnalysisCanvas
   } else {
-    picture_->draw(canvas, callback);
+    canvas->drawPicture(picture_.get());
   }

[reveman, 2014/09/22 21:29:05]

I assume this is the fix for picture ops being being parsed twice as mentioned
in the description. Can you move this to a separate patch and explain a bit more
why the old code is wrong? I'm not sure I understand exactly why this is
needed..

[hendrikw, 2014/09/22 21:48:39]

I'd rather not separate these.  I can put more details in the comments if you
like.

Essentially, picture->draw will parse the ops --and-- canvas->drawPicture could
parse the ops, or it could put the whole picture in the canvas as one operation,
depending on the canvas implementation.

We need this for the SkMultiPicture because we'll end up parsing the ops one
extra time, since we parse the ops when we call picture->draw(), then again when
we SkMultiPicture->draw()

[reveman, 2014/09/22 22:41:08]

Ok, a comment here would be useful as it's not obvious what the differences
between these calls are. Maybe just make it clear that drawPicture is preferred
when possible as it's in some cases more efficient. Btw, why doesn't drawPicture
take a callback?

[robertphillips, 2014/09/23 12:54:55]

We have renamed SkPicture::draw to be SkPicture::playback in Skia (and will be
pushing that change out to Chrome soon). So ...

SkPicture::playback replays the picture into another canvas and is intended for
clients that want to see all the operations replayed (e.g., AnalysisCanvas).
Interruption of playback is supported for exactly the AnalysisCanvas' early out
behavior. SkPicture::playback will always unfurl the picture!

SkCanvas::drawPicture is intended for when the client wants to draw the picture.
In this case it is assumed the client wants to draw the entire picture and not
interrupt it at some arbitrary point (and leave the receiving canvas in some odd
state). Since the SkPicture is passed in as an object the target canvases can
ref it  if needed (e.g., the recording canvas from
SkPictureRecorder::beginRecording) rather then unfurling it.

[reveman, 2014/09/23 14:59:46]

Ok, that makes sense. We should probably change the cc::Picture API to better
match skia instead of trying to do everything in Picture::Raster(). Maybe split
it into Picture::Draw and Picture::Playback.

   SkIRect bounds;
   canvas->getClipDeviceBounds(&bounds);
   canvas->restore();
   TRACE_EVENT_END1(
       "cc", "Picture::Raster",
       "num_pixels_rasterized", bounds.width() * bounds.height());
   return bounds.width() * bounds.height();
 }
 
 void Picture::Replay(SkCanvas* canvas) {
@@ skipping 175 matching lines @@
   scoped_refptr<base::debug::TracedValue> record_data =
       new base::debug::TracedValue();
   TracedValue::SetIDRef(this, record_data.get(), "picture_id");
   record_data->BeginArray("layer_rect");
   MathUtil::AddToTracedValue(layer_rect_, record_data.get());
   record_data->EndArray();
   return record_data;
 }
 
 }  // namespace cc