android: content::UIResourceProvider and content::UIResourceClientAndroid

content/browser/android/ui_resource_provider_impl.cc

Index: content/browser/android/ui_resource_provider_impl.cc
diff --git a/content/browser/android/ui_resource_provider_impl.cc b/content/browser/android/ui_resource_provider_impl.cc
new file mode 100644
index 0000000000000000000000000000000000000000..2b7df1f46141b9dbb904893ec0f66240e851a2ce
--- /dev/null
+++ b/content/browser/android/ui_resource_provider_impl.cc
@@ -0,0 +1,60 @@
+// 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 "content/browser/android/ui_resource_provider_impl.h"
+
+#include "cc/resources/ui_resource_client.h"
+#include "cc/trees/layer_tree_host.h"
+#include "content/public/browser/android/ui_resource_client_android.h"
+
+namespace content {
+
+UIResourceProviderImpl::UIResourceProviderImpl() : host_(NULL) {
+}
+
+UIResourceProviderImpl::~UIResourceProviderImpl() {
+  SetLayerTreeHost(NULL);
+}
+
+void UIResourceProviderImpl::SetLayerTreeHost(cc::LayerTreeHost* host) {
+  if (host_ == host)
+    return;
+  UIResourcesAreInvalid();

[David Trainor- moved to gerrit, 2014/06/04 07:22:41]

Do we have to worry about this calling back into this class to try to rebuild
resources with the incorrect host?  What happens if we set host_ first?

[powei, 2014/06/04 21:29:57]

Maybe this line should come after next line.  That way if the user does try to
re-create any ui resources, they'll just get 0 if the host is null.

+  host_ = host;
+}
+
+void UIResourceProviderImpl::UIResourcesAreInvalid() {
+  for (UIResourceClientMap::iterator iter = ui_resource_client_map_.begin();
+       iter != ui_resource_client_map_.end();
+       iter++) {
+    iter->second->UIResourceIsInvalid();
+  }
+  ui_resource_client_map_.clear();

[David Trainor- moved to gerrit, 2014/06/04 07:22:41]

Same thing, what if the client tries to recreate a resource id here in
UIResourceIsInvalid?  I feel like we should support that case.  I can see that
being a clean way to implement a client actually...

[powei, 2014/06/04 21:29:57]

Essentially I was thinking that we should not recreate when this signal is
received.  

My thought is that we generate UI resource only when an UI resource Id is
requested right before attaching that Id to a layer.  At that point, the user
should be fairly safe in that the compositor state is ok, and we're ok to
generate an UI resource.  

On the other hand, I think you're suggesting that an UI resource should be
created whenever the client gets the UIResourcesAreInvalid signal.  At that
point, either the LTH is there, and resources are created successfully or LTH is
gone, and we get 0s.  I guess we also need to try to create at client's
initialization.  

The trouble here is that if we keep around the UI resource clients even when the
Ids are invalid, then we'd have to add another method to allow for the client to
detach itself from the provider.  Delete and detach would become separate
concepts.  Would you prefer this?

+}
+
+cc::UIResourceId UIResourceProviderImpl::CreateUIResource(
+    UIResourceClientAndroid* client) {
+  if (!host_)
+    return 0;
+  cc::UIResourceId id = host_->CreateUIResource(client);
+  DCHECK(ui_resource_client_map_.find(id) == ui_resource_client_map_.end());
+
+  ui_resource_client_map_[id] = client;
+  return id;
+}
+
+void UIResourceProviderImpl::DeleteUIResource(cc::UIResourceId ui_resource_id) {
+  UIResourceClientMap::iterator iter =
+      ui_resource_client_map_.find(ui_resource_id);
+  if (iter == ui_resource_client_map_.end())
+    return;
+
+  ui_resource_client_map_.erase(iter);
+
+  if (!host_)
+    return;
+  host_->DeleteUIResource(ui_resource_id);
+}
+
+}  // namespace content