716581 - Investigate tile-by-tile rendering to reduce checkerboarding

Status: RESOLVED WONTFIX

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

Description

[Patrick Walton (:pcwalton)]

Tile-by-tile rendering could be used to minimize checkerboarding. We may be able to, when panning, retain old tiles and replace tiles that are far from the viewport with new tiles to cover checkerboarded areas.

Comment 1

[Patrick Walton (:pcwalton)]

Attachment: Early WIP patch.

Here's an early WIP patch. Needs the logic to actually prioritize the tiles properly, so it's not ready to go by any means yet.

Comment 2

[Patrick Walton (:pcwalton)]

Per a discussion on IRC the plan is to wait on Chris's patches and go from there.

Comment 3

[Patrick Walton (:pcwalton)]

Attachment: Early WIP patch, part 2.

Here's another very early WIP part that begins the inversion of control flow necessary to get MultiTileLayer to yield tile batches for incremental rendering. Most of the code is commented out and simplified and a bunch of unnecessary locks have been added. I believe I've gotten the races out, so it's now time to clean up the locks and restore functionality.

Once that's done, the first patch needs to be cleaned up and rebased on top of this patch.

Comment 4

[Chris Lord [:cwiiis]]

Comment on attachment 591705 [details] [diff] [review]
Early WIP patch, part 2.

Review of attachment 591705 [details] [diff] [review]:
-----------------------------------------------------------------

Just a note to say that I like the approach shown in this patch. Obviously still a bit to go, but good stuff.

Comment 5

[Patrick Walton (:pcwalton)]

Looks like actually rendering tile-by-tile is extremely slow. It is about the same speed as rendering the entire buffer atomically. Next try is to make a batch equal to a rect, and render one rect atomically.

Comment 6

[Patrick Walton (:pcwalton)]

Attachment: Early WIP patch, part 3.

Here's a WIP that (incorrectly) does tile-by-tile rendering.

Comment 7

[Chris Lord [:cwiiis]]

It doesn't surprise me that this is slow, but it's going in the right direction. This will only be fast, I guess, when you add cancellation.

Currently it'll draw the tiles which intersect with the screen first in one batch (good, and this one step ought to be faster than drawing every tile in the buffer... If it isn't, we have a problem), but it'll then update each off-screen tile one-by-one, and it'll be doing a draw between each one and blocking Gecko. We probably never want that to happen.

The batching needs to be more intelligent and there needs to be cancellation. I'd say, the first batch should be the screen, the second batch should be all tiles in the direction of scroll and the third batch should be any tiles left over within the current viewport + LayerController.MIN_BUFFER. Any tiles beyond that should just be ignored, and if the current viewport moves so that it's within the danger zone, the draw should be cancelled after the first batch.

Tiles off-screen may still want to be uploaded one-by-one, but they shouldn't be drawn one-by-one. I may well be wrong, in which case, maybe we do want to draw tiles one-by-one, but I'd have thought that the overhead of calling back into Java and running as much code as that between every Gecko draw would be quite large.

Comment 8

[Patrick Walton (:pcwalton)]

Attachment: Early WIP patch, part 1, version 2.

Comment 9

[Patrick Walton (:pcwalton)]

Attachment: Early WIP patch, part 2, version 2.

Comment 10

[Joe Drew (not getting mail)]

We're going to do OMTC rather than tile rendering.