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

Fri Feb 11 11:49:25 PST 2011

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

--- Comment #17 from Adam Roben (aroben) <aroben at apple.com>  2011-02-11 11:49:25 PST ---
Some discussion from #webkit yesterday:

<aroben>    ggaren: othermaciej: I haven't found any [Chromium] code yet that deletes backing stores after some amount of inactivity
<aroben>    ggaren: othermaciej: I've just seen an MRU cache for backing stores
<othermaciej>    http://src.chromium.org/svn/trunk/src/chrome/browser/renderer_host/backing_store_manager.cc
<othermaciej>    MRU implies the least recently used aren't in there
<ggaren>    aroben: indeed -- it seems like chromium only evicts one backing store to make room for another
<aroben>    ggaren: othermaciej: of course, an MRU cache would eventually lead to deleting backing stores after inactivity, assuming *someone* is painting somewhere
<aroben>    jinx-ish
<othermaciej>    MRU means you take a fixed cost, not an unbounded per-tab cost, I guess
<othermaciej>    that might be better than a timeout approach, hard to say
<ggaren>    i think it would be better in cases of fast switching between many tabs on a limited system
<ggaren>    not sure if we care to optimize for that case
<othermaciej>    I'm not sure I follow your logic of what case it would be good for
<othermaciej>    the pros and cons seem to be:
<othermaciej>    - capped high-water mark (so you can't get up to insane memory use just by cycling through a lot of tabs once)
<othermaciej>    - maybe somewhat slower if you cycle through all your tabs quickly twice
<othermaciej>    - higher low-water mark, since it won't purge below the cap
<othermaciej>    I suspect once you store enough backing stores to cause system memory pressure, you are not getting a speed benefit from having them around
<othermaciej>    I guess the MRU system also means that if you switch to another tab for a decent while (like a minute) to read something, switching back is very fast
<othermaciej>    one could imagine a system in between with high-water and low-water marks that are not equal
<othermaciej>    and when above the low-water mark, you evict on a timer
<othermaciej>    I could also imagine incorporating a value metric in addition to just size
<othermaciej>    note that having extra backing stores does more than just optimize tab switching in the normal case, it also makes it smoother when the web process is out to lunch
<ggaren>    othermaciej: what does "smoother" mean?
<othermaciej>    it means, you can switch tabs when the web process is busy or hung and see the contents of that tab
<ggaren>    where otherwise you would see white or something?
<othermaciej>    instead of contents of previously viewed tab or blank white
<evmar>    the killer with backing stores is that if they get swapped out, it's generally way faster to rerender the page than to wait for the image to come back from the disk.  (depends on where you keep backing stores though, on windows we keep them in plain ol' system ram)
<othermaciej>    (not sure which would happen, but those would be the options)

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