[Webkit-unassigned] [Bug 95758] [chromium] Adjust texture priorities in preparation of impl-thread eviction of only some textures

[bugzilla-daemon at webkit.org]

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





--- Comment #13 from Christopher Cameron <ccameron at chromium.org>  2012-09-05 10:51:02 PST ---
To take a step back, the goal of this change is to tweak the priorities so that I can put tabs into states of
- "only use video memory for what is on-screen" (say, for a cold backgrounded tab)
- "only use video memory for what is nearly on-screen" (say, for a warm backgrounded tab)
- "use as much video memory as you want, but don't keep around tiles that are 10 screens away, since that's just wasteful" (say, for the current tab)

I moved the lingering state to be at a higher priority here because that state is often for elements that will suddenly appear on-screen (say, on mouse-over), and so I don't want to have them matter less than tiles that are basically infinitely far away.  This is to not regress these sorts of UIs when discarding textures that are very far away.  If I don't make this change, the I cannot discard in order of priority without discarding all lingering tiles before discarding any tiles that were visible many screens ago.

I changed the units for distance from pixels to viewports so that I can specify "discard all textures that are >1 viewport away" (and things to that effect) for memory management.

(In reply to comment #12)
> Viewport dimensions don't affect scrolling speed, so I also don't think it should matter if the viewport is tall and narrow or short and wide. Either way we should cache as far out each way that we can.

The issue with caching as far as we can is that that can be unbounded.  This work came out of the following bug, where, on a long page, we consumed 500MB of video memory caching previously rendered tiles.
http://code.google.com/p/chromium/issues/detail?id=141377

Keeping around everything we every rendered is wasteful.  It also doesn't make much sense considering how un-aggressive we are with pre-painting -- in the above bug, we pre-paint half of a screen (or so), in the direction we are most likely to scroll (to content we haven't seen), while we retain hundreds of screens of content that we have already seen.

Using unbounded amounts of video memory like this causes instability and poor performance -- some systems will keel over under the pressure (or silently start texturing across PCIE, etc), and we don't have reliable ways of seeing where pressure starts.

> And I agree with Eric about vertical. Maybe we cache faster in the vertical direction always, like 2:1 or 3:2 or something, 

Unless I have the math wrong (which I may), the math that is there treats the two axes independently.  It will not put the vertical caching at a disadvantage in, for example, a very wide window.  If you'd like to add an additional bias towards caching more vertical tiles, that's fine as well.

> but I don't see what the viewport size has to do with it. Did you have some particular scenario in mind?

The goal is to be able to say "keep around X screens worth of previously-rendered content", instead of "keep around X bytes worth of previously-rendered content (no matter how far away it is)".  I was considering having a rule of "keep X pixels around", but that unit of measure is very hard to reason about because of differing screen sizes.

The true answer about how much to keep around (and pre-paint) is "however much we need to not checkerboard when scrolling", which is a function of rasterization time and scroll speed.  Also of note is that on platforms with weaker GPUs and where there are not multiple visible windows, we may want to be more aggressive about caching.

This change doesn't add any new cutoffs -- they will need to be added very carefully.

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