So back from layout into graphics again! For the last few weeks, I’ve been working with Benoit Girard on getting progressive tile rendering finished and turned on by default in Firefox for Android. The results so far are very promising! First, a bit of background (feel free to skip to the end if you just want the results).
You may be aware that we use a multi-threaded application model for Firefox for Android. The UI runs in one thread and Gecko, which does the downloading and rendering of the page, runs in another. This is a bit of a simplification, but for all intents and purposes, that’s how it works. We do this so that we can maintain interactive performance – something of paramount important with a touch-screen. We render a larger area than you see on the screen, so that when you scroll, we can respond immediately without having to wait for Gecko to render more. We try to tell Gecko to render the most relevant area next and we hope that it returns in time so that the appearance is seamless.
There are two problems with this as it stands, though. If the work takes too long, you’ll be staring at a blank area (well, this isn’t quite true either, we do a low-resolution render of the entire page and use that as a backing in this worst-case scenario – but that often doesn’t work quite right and is a performance issue in and of itself…) The second problem is that if a page is made up of many layers, or updates large parts of itself as you scroll, uploading that work to the graphics unit can take a significant amount of time. During this time, the page will appear to ‘hang’, as unfortunately, you can’t upload data to the GPU and continue to use it to draw things (this isn’t true in every single case, but again, for our purposes, it is).
Progressive rendering tries to spread this load by breaking up that work into several smaller tiles, and processing them one-by-one, where appropriate. This helps us mitigate those pauses that may happen for particularly complex/animated pages. Alongside this work, we also add the ability for a render to be cancelled. This is good for the situation that a page takes so long to render that by the time it’s finished, what it rendered is no longer useful. Currently, because a render is done all at once, if it takes too long, we can waste precious cycles on irrelevant data. As well as splitting up this work, and allowing it to be cancelled, we also try to do it in the most intelligent order – render areas that the user can see that were previously blank first, and if that area intersects with more than one tile, make sure to do it in the order that maintains visual coherence the best.
A cherry on the top (which is still very much work-in-progress, but I hope to complete it soon), is that splitting this work up into tiles makes it easy to apply nice transitions to make the pathological cases not look so bad. With that said, how’s about some video evidence? Here’s an almost-Nightly (an extra patch or two that haven’t quite hit central), with the screenshot layer disabled so you can see what can happen in a pathological case:
And here’s the same code, with progressive tile rendering turned on and a work-in-progress fading patch applied.
This page is a particularly slow page to render due to the large radial gradient in the background (another issue which will eventually be fixed), so it helps to highlight how this work can help. For a fast-to-render page that we have no problems with, this work doesn’t have such an obvious effect (though scrolling will still be smoother). I hope the results speak for themselves 🙂]]>
5 Replies to “Progressive Tile Rendering”
It would be great if this worked in desktop Firefox as well. It’s disappointing that scrolling is smoother on my smartphone than on my 50 W x86 machine.
The Metro version of Firefox uses an asynchronous compositor, but I don’t think it uses the tiles backend as far as I know. We’re currently working to get FirefoxOS using the tiles backend and progressive rendering, and I think there are long-term plans to get the desktop versions of Firefox using this same backend too, so they will likely also use this work, eventually. It’s not as easy on desktop, unfortunately, due to a much larger legacy and more concern over maintaining compatibility and behaviour across releases.
Did you ever do any benchmarking to see how much overhead was added by the tiling to the case where you wanted to draw every pixel on the screen?
Not explicitly that scenario, that I recall. The overhead of updating tiles vs. one large NPOT texture was basically negligible in this scenario though, and massively outweighed by the much more common scenario of many smaller sub-region updates. Tiled surfaces weren’t used for canvases or videos, which are the situations you might find them hurting.