cc: Support on demand raster with ganesh

cc/output/renderer.h

 // 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.
 
 #ifndef CC_OUTPUT_RENDERER_H_
 #define CC_OUTPUT_RENDERER_H_
 
 #include "base/basictypes.h"
 #include "cc/base/cc_export.h"
 #include "cc/quads/render_pass.h"
@@ skipping 22 matching lines @@
   bool using_map_image;
   bool using_discard_framebuffer;
   bool allow_rasterize_on_demand;
 
   RendererCapabilities MainThreadCapabilities() const;
 };
 
 class CC_EXPORT RendererClient {
  public:
   virtual void SetFullRootLayerDamage() = 0;
+  virtual bool UseTaskGraphRunnerForOnDemandRaster() = 0;

[reveman, 2014/06/18 01:18:28]

Would it be better to just have this take a resource id and a picture pile and
perform the raster in whatever way is appropriate?

[boliu, 2014/06/18 02:02:36]

Umm, not familiar with this area so not sure? Two questions.

SoftwareRenderer on-demand raster shouldn't be using any resources and it's part
of webview's requirement. So resource id doesn't make sense to me. I thought
on-demand raster is used (in chrome) during OOM when a tile doesn't get a
resource?

Also I noticed SoftwareRenderer uses RasterDirect but GLRenderer uses
RasterToBitmap. Seems the difference is important, so has to pass a bool/enum
for this?

[reveman, 2014/06/18 04:17:24]

SoftwareRenderer can use software resources, right? On-demand allow one resource
to be used to draw multiple tiles so the memory usage is constant.
I'm not sure why that is. Are you sure it makes a difference? If we can
initialize software resources in the tile manager without knowing if it's a
software resource then we should also be able to do that for on-demand raster.

[boliu, 2014/06/18 16:41:11]

Not webview's SoftwareRenderer I think? That one is specifically called
"resourceless software draw"; it just blimps into the SkCanvas that is backed
directly by the output surface software device. (In webview, the software device
is given to us by android view system and could already contains views below the
webview.) We avoid using auxillary bitmaps at all costs here; this draw doesn't
even use any auxillary bitmaps for blending (which is incorrect, but fast)

I think Alex has an internal talk on webview later today that will make this
clearer? Although I just learned about it just now and won't be attending..
So for the same reason above, SoftwareRenderer has to use RasterDirect.

GLRenderer could use RasterDirect too if it copies the code that clears the
SkCanvas I guess? But RasterToBitmap is also called tile_manager.cc (not
entirely sure what for) so can't get rid of it after.

[reveman, 2014/06/19 04:23:27]

Ok, in that case "RunOnDemandRasterTask(Task* on_demand_raster_task) is probably
better but I don't think we should use the same TaskGraphRunner instance as the
RasterWorkerPool instance for the gpu raster case.

 };
 
 class CC_EXPORT Renderer {
  public:
   virtual ~Renderer() {}
 
   virtual const RendererCapabilitiesImpl& Capabilities() const = 0;
 
   virtual void DecideRenderPassAllocationsForFrame(
       const RenderPassList& render_passes_in_draw_order) {}
@@ skipping 38 matching lines @@
   const LayerTreeSettings* settings_;
   bool visible_;
 
  private:
   DISALLOW_COPY_AND_ASSIGN(Renderer);
 };
 
 }  // namespace cc
 
 #endif  // CC_OUTPUT_RENDERER_H_