RESOLVED INVALID 91130
[chromium] Fix initialization race to determine the initial memory limit
https://bugs.webkit.org/show_bug.cgi?id=91130
Summary [chromium] Fix initialization race to determine the initial memory limit
Eric Penner
Reported 2012-07-12 11:56:05 PDT
In LayerRendererChromium, we set the memory limit via a callback: if (m_capabilities.usingGpuMemoryManager) m_context->setMemoryAllocationChangedCallbackCHROMIUM(this); else m_context->m_client->setMemoryAllocationLimitBytes(some_default); However, this leaves us with the question of what to do before we get the callback should we: - Wait for the callback before rendering anything? - Keep using a default a like we do currently? - Use a synchronous call to get the limit rather than a callback? It could decide whether to block etc. or just return the default itself? Another issue is that it is not effective to set the default in this location in LayerRendererChromium. Currently we also need to set it in the CCLayerTreeHostImpl constructor, so our initialization in LayerRendererChromium is not early enough.
Attachments
Dana Jansens
Comment 1 2012-07-12 11:58:38 PDT
Could we have a crbug for this? Manager peeps don't seem to watch w.b.o much.
Michal Mocny
Comment 2 2012-07-12 12:03:12 PDT
(In reply to comment #0) > In LayerRendererChromium, we set the memory limit via a callback: > > if (m_capabilities.usingGpuMemoryManager) > m_context->setMemoryAllocationChangedCallbackCHROMIUM(this); > else > m_context->m_client->setMemoryAllocationLimitBytes(some_default); > > However, this leaves us with the question of what to do before we get the callback should we: > - Wait for the callback before rendering anything? > - Keep using a default a like we do currently? > - Use a synchronous call to get the limit rather than a callback? It could decide whether to block etc. or just return the default itself? How is this functionally different from option 1? The time to get an allocation is the same in both case, right? Does initializing to 0 memory allocation somehow show us down? > > > Another issue is that it is not effective to set the default in this location in LayerRendererChromium. Currently we also need > to set it in the CCLayerTreeHostImpl constructor, so our initialization in LayerRendererChromium is not early enough.
Eric Penner
Comment 3 2012-07-12 12:16:33 PDT
(In reply to comment #2) > (In reply to comment #0) > > In LayerRendererChromium, we set the memory limit via a callback: > > > > if (m_capabilities.usingGpuMemoryManager) > > m_context->setMemoryAllocationChangedCallbackCHROMIUM(this); > > else > > m_context->m_client->setMemoryAllocationLimitBytes(some_default); > > > > However, this leaves us with the question of what to do before we get the callback should we: > > - Wait for the callback before rendering anything? > > - Keep using a default a like we do currently? > > - Use a synchronous call to get the limit rather than a callback? It could decide whether to block etc. or just return the default itself? > How is this functionally different from option 1? The time to get an allocation is the same in both case, right? Does initializing to 0 memory allocation somehow show us down? Just thinking out loud. It could hide the implementation and decision of whether to block and/or what default to give? Although the async way is likely preferred if we do always want to wait for a non-zero allocation.
Eric Penner
Comment 4 2012-07-12 12:30:26 PDT
Note You need to log in before you can comment on or make changes to this bug.