[Webkit-unassigned] [Bug 72686] [chromium] Need to prepaint tiles in TiledLayerChromium

Fri Nov 18 16:17:29 PST 2011

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

Adrienne Walker <enne at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |enne at google.com

--- Comment #6 from Adrienne Walker <enne at google.com>  2011-11-18 16:17:29 PST ---
(In reply to comment #5)

> In the second pass, when should we actually pre-paint? Would it be acceptable for pre-painting to be a no-op if there was a visible paint in the first pass? With a setNeedsCommit to defer the prepainting until later?  Also, do you agree with expanding the the pre-paint by one row/column at a time with setNeedsCommit in-between?

Yeah, as a first pass, each layer could locally decide if it wanted to do prepainting.  And, it could always call setNeedsCommit unless it knew it was done prepainting.  And, if we're at the texture limit, then we can just not request a commit until a commit gets kicked off by WebKit or from the compositor thread due to scrolling.

Prepainting one new row or column at a time seems like a reasonable heuristic.  If there's nothing else going on, the commit will be fast and we can prepaint more.

> Regarding reserving tiles, It sounds like that would also help with reserving pre-paint tiles, since it would slowly reserve tiles in order of importance.

Hrm.  The other thing is that reserving a tile means that it will be allowed to persist until the next frame, even over the soft reclamation limit.  We have two reclamation limits, one soft (which we'll fill up and not every bother going below) and one hard (which we'll never go above, but will temporarily go above if they're a lot visible at once).  If we reserve with the same mechanism, then we will always end up filling up towards the hard limit rather than the soft one.  And, even worse, the LRU mechanism in the texture manager will consider the prepainted tiles as a higher priority for eviction than on-screen tiles if we hit the upper limit, because they're the last thing reserved in the frame.

So, after some thought, I'm also wondering if we need a texture manager change here too to get desirable behavior.  :(

Just as a quick sketch of how this change could look: the texture manager needs to have a set (of two, for now?) LRU queues of different priorities.  When reserving in the texture manager, you'll need to pass an appropriate priority level so that the texture goes in the right queue.  Reserving texture can also change its priority (such as a prepainted tile becoming visible). When reducing texture memory in the texture memory (either to reserve something or during the evict stage), you should pull from the lower priority queue first until that's empty.  Reserving a lower priority texture should never reserve over the soft limit, whereas a high priority texture can.  That'll keep the texture limit sitting around the soft limit on average.

I don't mean to pile on an extra change here, but I'm not sure how else to make sure that we're not needlessly painting (i.e. still informing the texture manager about textures in use so we know when to stop prepainting because of texture limits) but also not interfere with normal texture operation (evicting things in the wrong LRU order with respect to least-recently-visible).

> I thought there might be a valid distinction between tiles that already have something something valid uploaded from a previous frame as opposed to an uninitialized texture or checkerboard. I thought worst case there would be a seam between the newly painted tiles and the old dirty tiles (until the dirty tiles get painted). Do you think it would be worse than that? 

Yeah, that worst case is exactly the problem.  So, if a tile's dirty, we'd prefer to checkerboard over showing that seam.

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