GpuMemoryManager suggests values for renderer Contents Texture Managers' preferred memory limit.

content/common/gpu/gpu_channel.cc

 // Copyright (c) 2012 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.
 
 #if defined(OS_WIN)
 #include <windows.h>
 #endif
 
 #include "content/common/gpu/gpu_channel.h"
 
@@ skipping 110 matching lines @@
     return false;
   }
 
   return channel_->Send(message);
 }
 
 void GpuChannel::AppendAllCommandBufferStubs(
     std::vector<GpuCommandBufferStubBase*>& stubs) {
   for (StubMap::Iterator<GpuCommandBufferStub> it(&stubs_);
       !it.IsAtEnd(); it.Advance()) {
-    stubs.push_back(it.GetCurrentValue());
+    GpuCommandBufferStub* stub = it.GetCurrentValue();

[nduca, 2012/04/18 23:16:28]

Is the idea here that we shouldnt give management callbacks to aura?

[mmocny, 2012/04/20 18:37:55]

Yes, until we get allocation hints I didn't want to give aura a large share of
the artificial limit.
Maybe this is not necessary but at the moment if you have only 1 window open,
aura has 2 stubs and a 3rd for popups etc so the wk renderer gets only 1/4 of
the global limit.
Maybe this is the wrong direction, but I wanted to prioritize wk compositor.
On 2012/04/18 23:16:28, nduca wrote:

+    if (stub->is_ui_stub())
+      continue;
+    stubs.push_back(stub);
   }
 }
 
 void GpuChannel::OnScheduled() {
   if (handle_messages_scheduled_)
     return;
   // Post a task to handle any deferred messages. The deferred message queue is
   // not emptied here, which ensures that OnMessageReceived will continue to
   // defer newly received messages until the ones in the queue have all been
   // handled by HandleMessage. HandleMessage is invoked as a
@@ skipping 282 matching lines @@
 
 #if defined(OS_POSIX)
 int GpuChannel::TakeRendererFileDescriptor() {
   if (!channel_.get()) {
     NOTREACHED();
     return -1;
   }
   return channel_->TakeClientFileDescriptor();
 }
 #endif  // defined(OS_POSIX)