Adding GpuMemoryManager to track GpuCommandBufferStub visibility and last_used_time and dictate mem…

content/common/gpu/gpu_channel.cc

Index: content/common/gpu/gpu_channel.cc
diff --git a/content/common/gpu/gpu_channel.cc b/content/common/gpu/gpu_channel.cc
index b9d4e05a5f69b40cad01578f4bf8338a8428afd8..87b061168653a0a60c249398732000111c0c8055 100644
--- a/content/common/gpu/gpu_channel.cc
+++ b/content/common/gpu/gpu_channel.cc
@@ -211,6 +211,15 @@ GpuCommandBufferStub* GpuChannel::LookupCommandBuffer(int32 route_id) {
   return stubs_.Lookup(route_id);
 }
 
+std::vector<GpuCommandBufferStub*> GpuChannel::GetCommandBuffers() {

[nduca, 2012/01/27 10:10:13]

Better to return the stubmap and let the code upstream do the iteration. You're
doing a copy here. :(

[Ken Russell (switch to Gerrit), 2012/01/27 19:21:24]

Returning the StubMap would expose more implementation details of the
GpuChannel. If this isn't performance critical code then returning a vector
seems fine to me.

[mmocny, 2012/01/27 19:51:33]

I had it that way at first, but this was cleaner.  The map is a nasty data
structure for external clients to know about..  And can't we rely on return
value optimization here?
Its an easy change so I won't argue too much.

On 2012/01/27 10:10:13, nduca wrote:

+  std::vector<GpuCommandBufferStub*> ret;
+  for (StubMap::Iterator<GpuCommandBufferStub> it(&stubs_);
+      !it.IsAtEnd(); it.Advance()) {
+    ret.push_back(it.GetCurrentValue());
+  }
+  return ret;
+}
+
 bool GpuChannel::OnControlMessageReceived(const IPC::Message& msg) {
   // Always use IPC_MESSAGE_HANDLER_DELAY_REPLY for synchronous message handlers
   // here. This is so the reply can be delayed if the scheduler is unscheduled.