Move SharedBitmapManager implementation out of content/

content/child/blob_storage/webblobregistry_impl.cc

Index: content/child/blob_storage/webblobregistry_impl.cc
diff --git a/content/child/blob_storage/webblobregistry_impl.cc b/content/child/blob_storage/webblobregistry_impl.cc
index 5032ed19446c6116fb48c6f6f4f487d922779a9e..ad7507dd4e15797ae2a57cfb2d721a59ee00617d 100644
--- a/content/child/blob_storage/webblobregistry_impl.cc
+++ b/content/child/blob_storage/webblobregistry_impl.cc
@@ -15,6 +15,7 @@
 #include "base/metrics/histogram_macros.h"
 #include "base/numerics/safe_conversions.h"
 #include "base/trace_event/trace_event.h"
+#include "components/display_compositor/child/child_shared_bitmap_manager.h"
 #include "content/child/blob_storage/blob_consolidation.h"
 #include "content/child/blob_storage/blob_transport_controller.h"
 #include "content/child/child_thread_impl.h"
@@ -152,7 +153,8 @@ void WebBlobRegistryImpl::addDataToStream(const WebURL& url,
     size_t shared_memory_size =
         std::min(length, limits_.max_shared_memory_size);
     std::unique_ptr<base::SharedMemory> shared_memory(
-        ChildThreadImpl::AllocateSharedMemory(shared_memory_size));
+        display_compositor::ChildSharedBitmapManager::AllocateSharedMemory(

[danakj, 2017/02/28 20:34:57]

I don't think this is right, because this method has nothing to do with
SharedBitmaps. Either:

a) The ChildSharedBitmapManager should be somewhere else, or
b) This method should be duplicated in to ChildSharedBitmapManager (privately)
and somewhere for this to use, or
c) This method should exist where this can use it (ChildThreadImpl maybe), and
be passed in to ChildSharedBitmapManager as a function pointer?

Maybe jam@ has some opinions.

Putting the Host stuff in display_compositor seems good.

The Child stuff in display_compositor/child seems okay, but seeing as it
allocates thru mojo, maybe it should just be in cc/surfaces/? That is where
other things used by all embedders of display_compositor clients live, that
don't depend on stuff in content, which it appears to be the case now. And the
display_compositor/interfaces/ could be in cc/ipc/ then? wdyt?

[xlai (Olivia), 2017/03/01 20:02:45]

This AllocateSharedMemory is currently attached in ChildThreadImpl and
childsharedbitmapmanager uses it. Having a duplicate private
method in ChildSharedBitmapManager looks a fine approach. Or, putting the whole
chain of childSharedBitmapManager in cc/surfaces looks fine too, just need to
introduce build/build_config.h
to cc/.

I personally prefer the first approach as most users of ChildSharedBitmapManager
lies in content/child and content/renderer and this seems like just another
symmetric example as 
//components/discardable_memory/client. WDYT?

[danakj, 2017/03/03 19:21:55]

I don't think either is the right final state. cc/surfaces/ is a bit of a mix of
client and service side and we can improve that. But I don't think we should
have client stuff inside the display_compositor component, as that duplicates
the cc/surfaces problem.

John's suggestion of MojoCreateSharedBuffer() would avoid needing to duplicate
or inject AllocateSharedMemory into cc/. Though I'm not totally sure how that's
better than using mojo::SharedBufferHandle::Create tbh.

+            shared_memory_size));
     CHECK(shared_memory.get());
     if (!shared_memory->Map(shared_memory_size))
       CHECK(false);