Serialize DisplayListRecordingSource to protos.

cc/playback/display_item_list.cc

 // Copyright 2014 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/playback/display_item_list.h"
 
 #include <string>
 
 #include "base/numerics/safe_conversions.h"
 #include "base/strings/stringprintf.h"
@@ skipping 49 matching lines @@
                               DisplayItemListSettings(proto.settings()));
 
   for (int i = 0; i < proto.items_size(); i++) {
     const proto::DisplayItem& item_proto = proto.items(i);
     DisplayItem* item = DisplayItemProtoFactory::AllocateAndConstruct(
         layer_rect, list.get(), item_proto);
     if (item)
       item->FromProtobuf(item_proto);
   }
 
+  list->Finalize();
+
   return list;
 }
 
 DisplayItemList::DisplayItemList(gfx::Rect layer_rect,
                                  const DisplayItemListSettings& settings,
                                  bool retain_individual_display_items)
     : items_(LargestDisplayItemSize(),
              LargestDisplayItemSize() * kDefaultNumDisplayItemsToReserve),
       settings_(settings),
       retain_individual_display_items_(retain_individual_display_items),
@@ skipping 122 matching lines @@
   // The last item should not have been handled by ProcessAppendedItems, so we
   // don't need to remove it from approximate_op_count_, etc.
   DCHECK(retain_individual_display_items_);
   DCHECK(!settings_.use_cached_picture);
   items_.RemoveLast();
 }
 
 void DisplayItemList::Finalize() {
   // TODO(wkorman): Uncomment the assert below once we've investigated
   // and resolved issues. http://crbug.com/557905
   // DCHECK_EQ(items_.size(), visual_rects_.size());

[vmpstr, 2015/12/10 01:12:18]

FYI, when this DCHECK gets uncommented, then this code will break. I'm not sure
what we should be doing here.

Here's what happens right now (and by now I mean in the near future):

We build up display item list, which builds up the items and visual_rects. In
finalize, we use the visual rects to build an rtree and clear the visual rects.
Then, at raster time we can use the rtree for the indices that index into items.

At what point do you expect that this list will be ToProtof-ed? We either need
the visual rects or the rtree serialized, since that's important for raster
performance. That is, the client side can't reconstruct these rects.

(this is also possibly my bad that visual rects were added without the
serialization code being updated).

[David Trainor- moved to gerrit, 2015/12/10 17:10:09]

We protobuf it during the commit phase and don't actually do any
PushPropertiesTo call on the layer in the engine (although we'll simulate what
we have to after the serialization to keep state working properly).

What would be easiest for us to send and cache on the client?  Ideally we'll
start caching DisplayItems on the client and only sending new ones.  I'll take a
look at this in a follow up patch today/tomorrow.

[vmpstr, 2015/12/10 18:55:44]

We need both the display list and visual rects on the client. The problem is
that when we call finalize, the visual rects are converted into an rtree. That's
why it's not clear to me if we serialize to protobuf before finalize or after
finalize? I image it's after. If that's the case we have two options:

1. Save off visual rects before finalize and serialize those
2. Serialize the rtree post the fact.

I would prefer 1... 

Can you file a bug and add a TODO probably around this line that says that we
have to deal with serialization of visual rects.

 
   // TODO(vmpstr): Build and make use of an RTree from the visual
   // rects. For now we just clear them out since we won't ever need
   // them to stick around post-Finalize. http://crbug.com/527245
   visual_rects_.clear();
 
   ProcessAppendedItems();
 
   if (settings_.use_cached_picture) {
     // Convert to an SkPicture for faster rasterization.
@@ skipping 97 matching lines @@
           DisplayItemsTracingEnabled()));
 }
 
 void DisplayItemList::GenerateDiscardableImagesMetadata() {
   DCHECK(ProcessAppendedItemsCalled());
   // This should be only called once, and only after CreateAndCacheSkPicture.
   DCHECK(image_map_.empty());
   DCHECK(!settings_.use_cached_picture || picture_);
   if (settings_.use_cached_picture && !picture_->willPlayBackBitmaps())
     return;
-

[vmpstr, 2015/12/10 01:12:18]

Undo this change please :)

[David Trainor- moved to gerrit, 2015/12/10 17:10:09]

Oops.

   // The cached picture is translated by -layer_rect_.origin during record,
   // so we need to offset that back in order to get right positioning for
   // images.
   DiscardableImageMap::ScopedMetadataGenerator generator(
       &image_map_, gfx::Size(layer_rect_.right(), layer_rect_.bottom()));
   Raster(generator.canvas(), nullptr,
          gfx::Rect(layer_rect_.right(), layer_rect_.bottom()), 1.f);
 }
 
 void DisplayItemList::GetDiscardableImagesInRect(
     const gfx::Rect& rect,
     float raster_scale,
     std::vector<DrawImage>* images) {
   image_map_.GetDiscardableImagesInRect(rect, raster_scale, images);
 }
 
 }  // namespace cc