During image destroy, delete textures only if we have a GL context.

content/common/gpu/gpu_command_buffer_stub.cc

Index: content/common/gpu/gpu_command_buffer_stub.cc
diff --git a/content/common/gpu/gpu_command_buffer_stub.cc b/content/common/gpu/gpu_command_buffer_stub.cc
index 189215122af0bff2aeb71e88d7364c1a7ad0fe21..25b14411d8323bc1ef9cbc0e5fbcb1fba213a858 100644
--- a/content/common/gpu/gpu_command_buffer_stub.cc
+++ b/content/common/gpu/gpu_command_buffer_stub.cc
@@ -946,7 +946,8 @@ void GpuCommandBufferStub::OnRegisterGpuMemoryBuffer(
   if (decoder_) {
     gpu::gles2::ImageManager* image_manager = decoder_->GetImageManager();
     DCHECK(image_manager);
-    image_manager->AddImage(image.get(), id);
+    if (!image_manager->AddImage(image.get(), id))
+      return;

[reveman, 2014/07/30 14:11:12]

I just remembered the second reason to why I prefer the check using LookupImage
from here instead of in the tile manager. If this fails, we now have to create a
GLImage instance and then destroy it. But if the check was done from here we
could check that it's a valid ID before we create the GLImage.

If you keep this as is, then you have to call Destroy on the image here when
adding it fails. However, I would much prefer to not create the image in the
first place if the ID is invalid. sievers@, what do you think?

[no sievers, 2014/07/30 14:46:46]

Normally I'd say it makes more sense to optimize it for the expected case (one
lookup instead of two) than the failure path. However, it's a hash map and the
number of items will be comparably small anyhow (or we have other perf
problems).
So either is totally fine with me. As long as it behaves robustly (see your
other comment), please land. I don't want to delay sohan further by nitpicking
:) This patch is a good improvement.

[sohanjg, 2014/07/30 15:02:44]

thanks :)

   }
 }