742757 - Implement on-demand, tiled drawing

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect)

Description

[Chris Lord [:cwiiis]]

With the work going on to draw into tiled areas to correspond to the tiled texture that fronts it, it makes sense that we draw on demand, rather than having the drawing driven by Gecko in response to events sent.

Doing this would allow us to more intelligently retain tiles of the page, and to respond quicker to movement/do less unnecessary drawing. It would also allow us to more easily interrupt drawing, in the situation that we can't keep up with what's being drawn on the screen, and should make viewport prediction (bug 729528) more efficient.

For the record, we attempted something similar when using the Java compositor, in bug 716581.

I think there are a few ways we can go about this, here's one:

- Separate layer size from buffer size
- Manually size the display-port to the size of the page
- Rename 'draw' events to 'invalidate' events, and just record the invalid region in layers
- Add interfaces necessary to request tiles be drawn via the CompositorParent (<-- massive simplification!)
- Augment the existing progressive texture upload code (bug 732917) to drive drawing as well as uploading tiles
- Optional: Improve the request interface and progressive upload code to prioritise tiles

The progressive tile upload code is already interruptable. We may use the current window size to pre-render some tiles before they're requested(?)


Another (maybe better, maybe harder) way of going about it would be to add a flag that would mark a frame 'boundless', somehow? (the equivalent of manually setting the displayport to the page size) This would make the display-port sizing part a lot less delicate.

Ideas very much welcome, especially from people that know layout and can point out the stupid assumptions I've probably made.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't yet understand what you're proposing, especially what happens on the main thread vs the compositor thread. Are you talking about doing tile uploads on the main thread synchronously with drawing?

Comment 2

[Chris Lord [:cwiiis]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #1)
> I don't yet understand what you're proposing, especially what happens on the
> main thread vs the compositor thread. Are you talking about doing tile
> uploads on the main thread synchronously with drawing?

No, though that'd certainly be nice (and will sort-of be the case when tiles are gralloc-backed).

I'm proposing the main thread will not do any drawing until asked to by the compositor thread - Instead, it will just keep track of what tiles it's been asked previously to render, and it will invalidate them as necessary.

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I don't fully understand what's being proposed either, but gecko has to drive drawing in many common cases like CSS animations/transitions, animated gifs, canvas, video, etc.  Round-tripping through the compositor adds latency.  This is the approach that was taken with fennec 2.0 and it worked badly for the examples above.

But again, don't fully understand the details here.

As a side note, it's very easy for us to interrupt drawing by having a flag in shmem that the compositor sets and our drawing code reads in critical loops.

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

BenWa - how is this related to the tile work you are doing?

Comment 5

[Benoit Girard (:BenWa)]

I'm already working on related feature in bug 771219, bug 783368.

Comment 6

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.