Bug 85801 – [chromium] setContentsMemoryAllocationLimitBytes needs to setNeedsCommit.

• Component: New Bugs
• Status: RESOLVED FIXED

[Michal Mocny]

[chromium] setContentsMemoryAllocationLimitBytes needs to setNeedsCommit.

[Michal Mocny]

Created attachment 140523 [details]
Patch

[Michal Mocny]

Comment on attachment 140523 [details]
Patch

This patch fixes: http://code.google.com/p/chromium/issues/detail?id=126079

On pages that did not need to update/draw, we would push a single white frame while our memory allocation was 0, and not push another frame once that memory allocation changed.

As well as calling setNeedsCommit, this patch resets the memory allocation to its initial value on visibility if it was purged down to 0.  This way, we can push a frame before waiting for a round trip memory allocation adjustments message to arrive.  If the message arrives before the next frame, great.  If not, at least our allocation is some conservative non 0 value, and also matches our current initialized state behaviour.

[Nat Duca]

Comment on attachment 140523 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=140523&action=review

> Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHost.cpp:382
> +    // Reset memory allocation to initial value if we have purged down to 0.

Why? This feels wrong... you're basically goign to let any newly visible tab ignore the gpu memory manager's recommendation?

> Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHost.cpp:427
> +    setNeedsCommit();

This part LGTM

[Michal Mocny]

Created attachment 140535 [details]
Patch

[Michal Mocny]

Comment on attachment 140523 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=140523&action=review

>> Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHost.cpp:382
>> +    // Reset memory allocation to initial value if we have purged down to 0.
> 
> Why? This feels wrong... you're basically goign to let any newly visible tab ignore the gpu memory manager's recommendation?

Discussed offline: it should be a separate bug to optimize returning from 0 memory allocation, as there are many possible solutions to this.
Removing from this patch for now.

[Adrienne Walker]

Comment on attachment 140535 [details]
Patch

R=me.  I agree with the approach of fixing this first and optimizing it later.

[WebKit Review Bot]

Comment on attachment 140535 [details]
Patch

Clearing flags on attachment: 140535

Committed r116316: <http://trac.webkit.org/changeset/116316>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.