Hey there! Did you hear this? Me neither. The 32nd episode of WebRender’s newsletter made its way to your screen without a sound. In the previous episode, nic4r asked in the comments section a lot of technical and interesting questions. There is a lot to cover so I’ll start by answering a couple here by way of introduction and will go through the other questions in later posts.
How do the strategies for OMTP and WebRender relate? Would OMTP have benefits for expensive blob rasterization since that used Skia?
OMTP, for off-main-thread painting, is a project completely separate from WebRender that was implemented by Ryan. Without WebRender, painting used to happen on the main thread (the thread that runs the JS event loop). Since this thread is often the busiest, moving things out of it, for example painting, is a nice win for multi core processors since the main thread gets to go back to working on JS more quickly while painting is carried out in parallel. This work is pretty much done now and Ryan is working on project Fission.
What about WebRender? WebRender moved all of painting off of the main thread by default. The main thread translates Gecko’s displaylist into a WebRender displaylist which is sent to the GPU process and the latter renders everything. So WebRender and OMTP, while independent projects both fulfill the goal of OMTP which was to remove work from the main thread. OMTP can be seen as a very nice performance win while waiting for WebRender.
Expensive blob rasterization is already carried out asynchronously by the scene builder thread (helped by a thread pool) which means we get with blob rasterization the same property that OMTP provides. This is a good segue to another question:
How do APZ and async scene building tie together?
APZ (for Asynchronous Panning and Zooming) refers to how we organize the rendering architecture in such a way that panning and zooming can happen at a frame rate that is decoupled from the expensive parts of the rendering pipeline. This is important because the perceived performance of the browser largely relies on quickly and smoothly reacting to some basic interactions such as scrolling.
With WebRender there are some operations that can cost more than our frame budget such as scene building and blob image rasterization. In order to keep the nice and smooth feel of APZ we made these asynchronous. In practice this means that when layout changes happen, we re-build the scene and perform the rasterization of blob images on the side while still responding to input events so that we can continue scrolling the previous version of the scene until the new one is ready. I hope this answers the question. Async scene building is one of the ways we “preserve APZ” so to speak with WebRender.
Notable WebRender and Gecko changes
- Jeff improved performance when rendering text by caching nsFontMetrics references.
- Jeff removed some heap allocations when creating clip chains.
- Jeff wrote a tool to find large memcpys generated by rustc.
- Dan continued working on scene building performance.
- Kats is helping with the AMI upgrade for Windows.
- Kats Fixed crashes due to large draw target allocations.
- Kats Got captures to work on Android.
- Kvark removed non-zero origin of reference frames stacking contexts and iframes.
- Kvark made a couple of memcpy optimizations.
- Kvark fixed replaying a release capture with a debug version of wrench.
- Kvark prevented tiled blob images from making captures unusable.
- Matt Improved the performance of displaylist building.
- Andrew fixed a rendering issue with animated images.
- Andrew fixed a crash.
- Glenn landed all of the primitive interning and picture caching patches, will probably enable picture caching soon. (1), (2), (3), (4), (5), (6), (8), (9) and (10). phew!
- Glenn added a scratch buffer for transient data during frame building.
- Glenn reduced the size of BrushPrimitive.
- Glenn added support for float keys in interning.
- Glenn fixed a bug with the update of uv rects in the texture cache.
- Nical and Gankro simplified tracking image dirty rects in WebRender.
- Nical stored tile dirty rects in local space.
- Nical refactored the blob image related APIs to be able to express some of the things we need for blob image re-coordination.
- Nical fixed a crash.
- Nical fixed a memory leak.
- Sotaro fixed a WebGL crash when Wayland is enabled.
- Sotaro fixed a rendering issue with SurfaceTexture on Android.
- Sotaro fixed an intermittent failure related to frame synchronization.
- Doug put document splitting up for review.
Ongoing work
- Bobby is working on improving the shader cache.
- Nical is working on blob image re-coordination.
- A lot of people in the team keep investigating performance with a focus on scene building and slow memcpys generated by rustc when medium/large structures are moved on the stack.
- Kats keeps improving the situation on Android.
- Lee continues improving font rendering.
- Markus is getting profiling with full symbol information to work on android.
Enabling WebRender in Firefox Nightly
In about:config, set the pref “gfx.webrender.all” to true and restart the browser.
Reporting bugs
The best place to report bugs related to WebRender in Firefox is the Graphics :: WebRender component in bugzilla.
Note that it is possible to log in with a github account.
Mozilla Gfx Team Blog 
Is the Android version usable yet?
Not yet. This is ongoing work and I’ll drop a note in the newsletter whenever we get there.
Font rendering…Pathfinder merged WebRender is too slow.
Excellent work, can’t wait for the image caching being enabled!
What are the next mid-future architectural plans for Webrender?
* Do you still plan to use pathfinder for font-rendering any time soon?
* What about planeshift?
* Using gfx-rs probably isn’t all that high in the priority list, but is this still being actively scoped?
We’d like to use pathfinder eventually but it’ll have to wait until we WebRender is shipped and stable, for now pathfinder can only emulate the native font look on mac and there are known issues so I suspect there’s some non-trivial amount of work left before we can ship it.
For planeshift I haven’t looked closely into it, I don’t know if it’s high level enough for us to bolt it onto Firefox or if we’ll need something a bit more specific, but we want to better integrate with OS compositors in the long run so the feature itself will make its way eventually.
There are people working on the gfx-rs port of WebRender. Still a lot to do but they have promising results. It’s most likely going to take a while before we ship it as well.
Thank you for the in-depth reply!
People, you keep posting tons of interesting stuff. But whats the ETA on WebRender????? Just keep us posted instead of keeping us in limbo. Its very very disappointing!!! When can be expect webrender in the release channel? In short, is it weeks away? Or months away? Or years away?
I’d guess 2-4 months for the Nvidia desktop configuration, 6 months for the general desktop population, and around a year for Android. But I’m not involved in WebRender development nor affiliated with Mozilla so who knows how close I am.
It’s probably hard even for Mozilla developers to say because something new like WebRender always has unexpected obstacles. I’m sure there’s a target version they’d like to release WebRender for, but it comes with a degree of uncertainty which is why it’s not public yet (as far as I know).
Anyways you can actively track progress by looking at the number of release blockers. 26 days ago there were 46 bugs and today there are 42 with 5 of those being new. The number is obviously bouncing around but still decreasing. Just remember that not every bug is the same as some take much more effort than others and typically it makes sense to work on fine-tuning last (which are the smaller bugs). https://bugzilla.mozilla.org/buglist.cgi?f1=blocked&f2=blocked&f3=blocked&f4=blocked&j_top=OR&known_name=gfx-webrender-v1-p1&o1=substring&o2=substring&o3=substring&o4=substring&priority=P2&resolution=—&v1=1386669