Bug 91130
Summary: | [chromium] Fix initialization race to determine the initial memory limit | ||
---|---|---|---|
Product: | WebKit | Reporter: | Eric Penner <epenner> |
Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | Normal | CC: | danakj, enne, epenner, mmocny |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Eric Penner
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 | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Dana Jansens
Could we have a crbug for this? Manager peeps don't seem to watch w.b.o much.
Michal Mocny
(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
(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
Removing as this is now here:
https://code.google.com/p/chromium/issues/detail?id=137094