743751 - [meta] Use low res version of page to hide checkerboarding when zooming in and out and panning

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[JP Rosevear [:jpr]]

Cache low res version of page to hide checkerboarding when zooming in and out.

iPhone does this.

Comment 1

[Chris Lord [:cwiiis]]

Here's my fuzzy plan of action on this:

- Setting clipSubdocument to false will cause us to get invalidations for the entire page, instead of just a sub-section. I don't think this will have performance implications - invalidations go through the frame-tree, which exists regardless of window/display-port size, and are only clipped once they reach the root scroll frame (well, they may be clipped by inner scroll frames, but that's fine)

- Add an Invalidate() function to Layers that invalidates the entire layer. Currently, there's just InvalidateRegion(nsIntRegion), which FrameLayerBuilder calls with GetValidRegion(). This is inefficient anyway, so this will be a nice thing to do and makes the code a little clearer to read.

- Add a second invalid region for this low-res cache to BasicTiledThebesLayer. This will be maintained independently of mValidRegion, though will still be affected by Invalidate/InvalidateRegion.

- Add a resolution parameter to BasicTiledLayerBuffer

- Add a secondary BasicTiledLayerBuffer to each BasicTiledThebesLayer that contains the low-res cache (using the resolution parameter to store its scale)

- Update this low-res cache. TODO: Decide when to do this... Maybe just in BasicTiledThebesLayer::PaintThebes and take the performance hit (it shouldn't be updated often), but this may be a concern.

- Communicate this secondary buffer, and its valid region, in TiledThebesLayerOGL::Swap

- In RenderLayer, check to see if there's any visible area the primary valid region doesn't cover. If there is, and the secondary valid region intersects with this, draw the secondary valid region

These steps should (apart from the first two) should only be carried out in the case that the layer size is lower than the associated frame size.


Things not covered in this plan:

Async render: I can't think of an easy way to do the rendering asynchronously, so this will have a momentary impact (hopefully just on first render) on the Gecko thread. This will depend on the size of the buffer and the complexity of the page.

Async upload: BenWa's current tiled layer patch doesn't do async upload yet - I would expect to do it in the same way I did it in bug #732917, but BenWa may come up with something better that affects this :)
We may want to upload entirely on demand for the low-res cache, as there's a very real possibility of it never being displayed and so uploading it may be pointless.

Comment 2

[Chris Lord [:cwiiis]]

After talking to Brad, he/we have another, easier (and probably better...) plan:

The basic idea is to have a (much?) larger displayport, but for the extremeties of the display-port to be rendered at a set, lower resolution. This would involve far fewer changes than the plan I detailed in comment #1 and ought to have nicer performance characteristics.

This would require adding a resolution propery to each tile, although that could be inferred by its intersection with the high-resolution area. When drawing, the resolution will be used in a transform to paint correctly. Iteration over tiles will get a little more complicated, but it ought not be too big a deal.

Comment 3

[Chris Lord [:cwiiis]]

Ok, another update - this second plan isn't feasible at the moment :(

BenWa's current tiles implementation does a Thebes layer render into a separate buffer from which it then copies into tiles - it does this, as rendering in sections directly into tiles is much slower.

I've discussed tiled rendering with Chris Wilson (cairo maintainer) before, and he suggested that it ought to be fast if we use recording surfaces (similar to Skia display lists). Although recording surfaces are in the in-tree Cairo 1.10, they're slow and buggy until Cairo 1.12. Jeff says a Cairo update isn't feasible to happen in the short-term.

My first plan could still work, but involves some quite involved changes and may have negative performance implications.


A third plan we've discussed is to use the existing page screenshotting code in idle time to do a low-res render of the entire page, which can then be used by placeholder tiles to render when they don't have a full resolution buffer available. This is currently being discussed.

Comment 4

[Chris Lord [:cwiiis]]

Seems I lost a comment here, or perhaps posted to the wrong bug...

We ended up deciding that a low res tile cache was not a useful thing to explore at this time, due to various limitations scuppering all the easy/fast/good ways of doing it.

We wrote up some of the findings/decisions here: https://etherpad.mozilla.org/FennecTiles

I'll be concentrating on working with Geoff to get tile retaining going - this, along with the continued work to improve performance will likely get us to a good position for release.

Comment 5

[Damon Sicore (:damons)]

(In reply to Chris Lord [:cwiiis] from comment #4)
> I'll be concentrating on working with Geoff to get tile retaining going -
> this, along with the continued work to improve performance will likely get
> us to a good position for release.

I don't think it's prudent or correct to hope that our other performance work is going to get us to a good position to release. 

We need a clear path to a checkerboard-less low-res page that is performant.

Comment 6

[JP Rosevear [:jpr]]

So, I filed bug 746016 for the java plan.  Part of an alternate plan is bug 745177, using retained tiles.  We can update this bug to be "multi-resolution displayport drawing" if we want, because I believe that is really the thing that was WONTFIXED.

Comment 7

[JP Rosevear [:jpr]]

Discussed several different approaches today:

1) Priority based tile queue

ICS does this, is probably the right long term approach.  Cache low res tiles outside the screen area on a priority basis.

2) Dual-res flinging

Change to lower resolution draws during flinging and back to higher resolution when slowing down.  Fails at zooms < 2x because fixed cost of drawing is high as a percentage of overall draw time.  Useful at > 2x zooms.

3) Retained tiles

Cache tiles using LRU.  Helps most of our use cases except aggressive fling to the bottom the first time you do it.

3a) Eviction to low res.

Eviction from the cache to a low res version.  Helps keep more tiles around.

4) Dual-res flinging on top of tiles

Same as #2, but using tiles.

5) Java screenshot

Snapshot the page on the Java UI side and use it for pan/zoom checkerboard fill.  Stale pages are an issue, may cause more checkboard.

6) Gecko-side dual displayport creation

Draw two different displayports at different resolutions and use the low res one to fill.  Complicated, might fail, 1+2+3+3a+4 probably easier and better.

Comment 8

[JP Rosevear [:jpr]]

We are looking at 5) and 3) right now for the first release.

Comment 9

[JP Rosevear [:jpr]]

Changing summary back and minusing - tile based priority queue should be a separate bug and not for the first release.