Don't clear visual rects when finalizing display item lists for now.

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 <stddef.h>
 
 #include <string>
 
@@ skipping 138 matching lines @@
 
 void DisplayItemList::Finalize() {
   TRACE_EVENT0("cc", "DisplayItemList::Finalize");
   // TODO(dtrainor): Need to deal with serializing inputs_.visual_rects.
   // http://crbug.com/568757.
   DCHECK(inputs_.items.size() == inputs_.visual_rects.size())
       << "items.size() " << inputs_.items.size() << " visual_rects.size() "
       << inputs_.visual_rects.size();
   rtree_.Build(inputs_.visual_rects);
 
-  if (!retain_visual_rects_)
-    // This clears both the vector and the vector's capacity, since
-    // visual_rects won't be used anymore.
-    std::vector<gfx::Rect>().swap(inputs_.visual_rects);
+  // TODO(wkorman): Restore the below, potentially with a switch to allow
+  // clearing visual rects except for Blimp engine. http://crbug.com/633750
+  // if (!retain_visual_rects_)

[Khushal, 2016/08/03 00:29:05]

We don't really need to do any post processing on the list, on the engine side.

Probably you can pass that in as a setting when building the DisplayList, so the
finalize method wouldn't do anything. You can use
switches::kUseRemoteCompositing to enable it.

[wkorman, 2016/08/03 00:37:00]

Yes, I wanted to do things more cleanly in a separate patch and land this just
to un-block folks. Do you want to wait or go with this today?

vmpstr@ and other cc folks I would normally have as reviewers are OOO all week.

Also, this change is needed to prevent engine from crashing, but your comment
reads as if it's not needed for engine, so I must be misinterpreting.

[Khushal, 2016/08/03 00:44:42]

Sorry for being unclear. I was suggesting that you could use the flag above to
have a setting to side-step the entire Finalize step altogether, taking that up
in a follow up patch is better.

+  //   // This clears both the vector and the vector's capacity, since
+  //   // visual_rects won't be used anymore.
+  //   std::vector<gfx::Rect>().swap(inputs_.visual_rects);
 }
 
 bool DisplayItemList::IsSuitableForGpuRasterization() const {
   // TODO(wkorman): This is more permissive than Picture's implementation, since
   // none of the items might individually trigger a veto even though they
   // collectively have enough "bad" operations that a corresponding Picture
   // would get vetoed. See crbug.com/513016.
   return inputs_.all_items_are_suitable_for_gpu_rasterization;
 }
 
@@ skipping 81 matching lines @@
 }
 
 void DisplayItemList::GetDiscardableImagesInRect(
     const gfx::Rect& rect,
     float raster_scale,
     std::vector<DrawImage>* images) {
   image_map_.GetDiscardableImagesInRect(rect, raster_scale, images);
 }
 
 }  // namespace cc