UI Resource Manager

cc/trees/layer_tree_host.h

Index: cc/trees/layer_tree_host.h
===================================================================
--- cc/trees/layer_tree_host.h	(revision 210393)
+++ cc/trees/layer_tree_host.h	(working copy)
@@ -23,6 +23,7 @@
 #include "cc/input/top_controls_state.h"
 #include "cc/layers/layer_lists.h"
 #include "cc/output/output_surface.h"
+#include "cc/resources/ui_resource_manager.h"
 #include "cc/scheduler/rate_limiter.h"
 #include "cc/trees/layer_tree_host_client.h"
 #include "cc/trees/layer_tree_host_common.h"
@@ -62,6 +63,7 @@
 class ResourceProvider;
 class ResourceUpdateQueue;
 class TopControlsManager;
+
 struct RenderingStats;
 struct ScrollAndScaleSet;
 
@@ -255,6 +257,17 @@
 
   bool in_paint_layer_contents() const { return in_paint_layer_contents_; }
 
+  // UI Resource management
+  UIResourceId CreateUIResource(scoped_refptr<UIResourceBitmap> bitmap,
+                                UIResourceManagerClient* client);
+  void UpdateUIResource(UIResourceId uid,
+                        scoped_refptr<UIResourceBitmap> bitmap,
+                        gfx::Rect update_region);
+  // Deletes a UI resource.  May safely be called more than once.
+  void DeleteUIResource(UIResourceId id);
+  void UIResourceReady(UIResourceId id);

[enne (OOO), 2013/07/09 17:57:48]

What does UIResourceReady mean? Does that mean that the texture is uploaded and
ready to draw? If so, what would you do in response to that notification on the
main thread?

[aelias_OOO_until_Jul13, 2013/07/09 20:22:19]

Yes, it means it's uploaded and ready to draw.

The main thread can respond by attaching the UIResourceID to a layer. Note that
attaching to a layer before this UIResourceReady call is allowed, however, it
may result in a framerate jank.  dtrainor@'s Android thumbnail usecase creates
large resources while animations are in progress, so this hint is useful there.

[enne (OOO), 2013/07/09 20:32:52]

Huh.  I guess I'm just curious about what you would do differently on the main
thread vs. the compositor thread.  When creating quads, the compositor-side
layer would still have to ask "can I get a resource for this id" and could
behave differently, while the main thread side doesn't have to care about the
state of the resource.

[aelias_OOO_until_Jul13, 2013/07/09 20:54:30]

My thinking is that the impl-side will always block in some way until the
resource is available -- because most users of UIResources never want to see a
"white flash" during texture upload.  Those few users -- i.e. the thumbnail
system -- who do consider "white flash" acceptable can manage that themselves on
the main thread using UIResourceReady.

+  void UIResourceLost(UIResourceId id);

[enne (OOO), 2013/07/09 17:57:48]

Do you think we'll ever want to lose just one resource vs. losing them all?

[aelias_OOO_until_Jul13, 2013/07/09 20:22:19]

Since the only cause is lost context in the current design, we can only lose
them all.  (I don't see much value in CC evicting UIResources due to memory
limits.)  It just seemed natural API-wise to have one call per UIResourceID --
one reasonable alternative would be to provide one call per client with a vector
of UIResourceIDs.

+
  protected:
   LayerTreeHost(LayerTreeHostClient* client, const LayerTreeSettings& settings);
   bool Initialize(scoped_refptr<base::SingleThreadTaskRunner> impl_task_runner);
@@ -281,6 +294,13 @@
 
   bool AnimateLayersRecursive(Layer* current, base::TimeTicks time);
 
+
+  typedef base::hash_map<UIResourceId, UIResourceManagerClient* >
+    UIResourceClientMap;
+  UIResourceClientMap ui_resource_client_map_;
+  int ui_resource_counter_;
+
+
   void CalculateLCDTextMetricsCallback(Layer* layer);
 
   bool animating_;