[Webkit-unassigned] [Bug 51262] WebPageProxy should delete its backing store after not painting for a while

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=51262





--- Comment #2 from Adam Roben (aroben) <aroben at apple.com>  2011-02-10 08:44:49 PST ---
Some info from discussions outside of Bugzilla:

Anders:
The design I imagined for this was that we have a maximum cap of backing stores and use a LRU list to figure out which backing store to evict. This could also be combined with a timer.

When a WKView is asked to paint and it doesn't have a backing store, it needs to send a request to the WebProcess and block for a little while so we won't get flashes.

Adam:
An LRU cache doesn't seem required to fix this bug.

Aren't we effectively triple-buffering on OS X (as we are on Windows with the DWM enabled)? I wonder if we can get rid of the extra buffer on OS X. Maybe the fact that we draw into a CGLayer prevents the triple-buffering? Again, not required to fix this bug.

Geoff:
One thing I'll mention about it: I think it's worth doing a basic measurement to figure out how long a full paint, starting with no backing store, takes on reasonably modern hardware. That way, we can come up with a time delay that has some methodology to it. For example, if a full paint takes 50ms, a 5s delay ensures a cost of only 50/5000 = 1%. But if a full paint takes only, say, 10ms, I'd make the timer even shorter.

Adam:
I guess this is a worst-case cost calculation. I.e., if we set the timer to 5s, and WebPageProxy has to paint every 5.000001s, then we'll spend 1% of the time recreating the backing store and painting into it. Of course, the other 99% of the time is spent doing nothing at all.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.