718388 - Use viewport 'prediction' to reduce checkerboarding

Status: RESOLVED DUPLICATE of bug 729528

(Firefox for Android Graveyard :: General, defect, P1)

Description

[Chris Lord [:cwiiis]]

With the tiling capability added in bug #717283, we should be able to 'predict' viewport locations to render more off-screen area and therefore reduce checkerboarding. This would obsolete the viewport offset (bug 710533).

Comment 1

[Chris Lord [:cwiiis]]

Attachment: Use viewport prediction to render off-screen content more intelligently (WIP)

This patch uses a 'predicted' viewport instead of the actual viewport during flinging, to more intelligently render off-screen content. At least, that's the idea. This patch removes viewport bias and moves setting the viewport offset into LayerController (which has a lot more context to do it). This allows the buffer size to be reduced, which is also done in this patch.

Currently showing signs of being able to work, but quite glitchy and very much work in progress. Uploading for feedback/discussion.

Comment 2

[Chris Lord [:cwiiis]]

Attachment: Use viewport prediction to render off-screen content more intelligently (WIP)

Sorry for spam, forgot to qref.

Comment 3

[Chris Lord [:cwiiis]]

Just a note, this patch would benefit greatly from tile-by-tile drawing and a tile-map rather than using contiguous memory, as we could prevent the buffer from being entirely locked during drawing (and fit in more texture updates per viewport update). Especially in the gralloc case, where the tile and texture memory will be shared.

Comment 4

[Chris Lord [:cwiiis]]

Attachment: Use viewport prediction to render off-screen content more intelligently (WIP)

This works a lot better than the last one and is less glitchy... Starting to get somewhere.

The main problem I see is gaps between viewport predictions when scrolling, which I think looks too odd, despite showing you more of the page than you would've seen before.

Comment 5

[Chris Lord [:cwiiis]]

The main reason for these gaps is the asynchronous update - disabling this, I get an almost checkerboard-free scroll on engadget.com (after fully loading, of course). This is heartening, in this case, I think I can work out a nicer heuristic to do the async updating in larger chunks that should make this work better.

Comment 6

[Chris Lord [:cwiiis]]

After playing around with it a bit, I can't think of a good heuristic for doing off-screen updates that will work with this patch... On the other hand, now that I've reduced the buffer size, I don't actually need async updates to maintain smooth frame updates...

So any thoughts on just disabling them and updating the entire dirty region at once?

With tiles, and the buffer not being much bigger than the screen, this really shouldn't be too different anyway (the async update makes sense with a large buffer though).

Comment 7

[Chris Lord [:cwiiis]]

Attachment: Use viewport prediction to render off-screen content more intelligently

Disabled async updates, but left a static boolean flag to enable, along with a comment explanation.

This, and its dependent tiling patch make panning a much nicer experience on my HTC Flyer. Not checkerboard-free, but there's much less of it, and the decreased buffer size improves update performance considerably.

The decreased buffer size does mean that you can now quite easily pan to the checkerboard though, so if this lands, we may want to consider either enabling updates during pan, or having some kind of dynamic buffer size. Given flinging is smooth, I think enabling updates during pan should be a reasonable option.

Comment 8

[Chris Lord [:cwiiis]]

Comment on attachment 588965 [details] [diff] [review]
Use viewport prediction to render off-screen content more intelligently

In my haste, I forgot that I haven't made this work for gralloc devices - this will break behaviour in that case.

Rather than add more if/else's all over the place, I'll file a new bug about getting tiling working on gralloc tomorrow and make this patch depend on that.

I'd still like review though, so if this feedback could be treated as review, excepting the issue that this breaks the gralloc path, that'd be appreciated.

Comment 9

[Patrick Walton (:pcwalton)]

I'm a bit confused -- why do we want a small buffer size? It seems to me that this would make checkerboarding worse in some cases, because we have to discard more tiles once they're outside the buffer.

If viewport prediction improves things, then that's fine, but I'm a little wary of decreasing the buffer size if we're about to land tile-by-tile rendering, which should eliminate the penalty associated with a large buffer size.

Comment 10

[Chris Lord [:cwiiis]]

I'm not sure what you mean about discarding more tiles once they're outside the buffer? Either way, the problem with a large buffer size is that it increases the time it takes Gecko to respond to viewport changes, and increases memory use.

The great thing about having a separate tile store is that we can reduce the Gecko buffer size - this decreases our rendering time/CPU usage/memory pressure and lets us respond much quicker.

The tile pool allows us to move the viewport away from the screen, so during flinging, we have a much larger 'virtual' buffer size. As we have to discard tiles once they're off the screen and not in the buffer, reducing the buffer size improves checkerboarding when you change directions very quickly.

Reducing the buffer size also lets us update textures synchronously again, which the viewport prediction pretty much needs (we could get around this with clever heuristics, but I don't see the point if reducing the buffer size only has positive effects and removes this problem).

Comment 11

[Patrick Walton (:pcwalton)]

(In reply to Chris Lord [:cwiiis] from comment #10)
> I'm not sure what you mean about discarding more tiles once they're outside
> the buffer? Either way, the problem with a large buffer size is that it
> increases the time it takes Gecko to respond to viewport changes, and
> increases memory use.
> 
> The great thing about having a separate tile store is that we can reduce the
> Gecko buffer size - this decreases our rendering time/CPU usage/memory
> pressure and lets us respond much quicker.
> 
> The tile pool allows us to move the viewport away from the screen, so during
> flinging, we have a much larger 'virtual' buffer size. As we have to discard
> tiles once they're off the screen and not in the buffer, reducing the buffer
> size improves checkerboarding when you change directions very quickly.

This is what I'm confused about -- won't reducing the buffer size mean that the maximum distance from the viewport that we're allowed to retain tile contents within decreases? So we could get more checkerboarding...

Comment 12

[Doug Turner (:dougt)]

tracking 11.

Comment 13

[Joe Drew (not getting mail)]

Kats is currently looking at this. I'm morphing this bug into a Maple-specific bug.

Comment 14

[Kartikaya Gupta (email:[e-mail])]

Duping to bug 729528.

Comment 15

[Patrick Walton (:pcwalton)]

Comment on attachment 588965 [details] [diff] [review]
Use viewport prediction to render off-screen content more intelligently

feedback- to get out of queue.