Better late than never for the 8th newsletter. On the WebRender side, things keep getting faster and look smoother which is always nice. On Gecko’s side the work is, as always, hard to summarize but there are some self contained bits worth getting excited about like the great progress on reducing the overhead of building and transferring the display list to the parent process.
Lin Clark wrote an excellent blog post about WebRender. Now that the post is out I’ll resume working on the the series I started about WebRender on this blog, focusing on areas that were not included in Lin’s post and going to delve into some of the gory details of 2D rendering. Hopefully I’ll have time to work on this soon.
Notable WebRender changes
- A large improvement in deserialization performance. This improved GMail drawing from 150fps to 200 fps
- Nical improved (and fixed bugs in) the anti-aliasing of all rendering primitives.
- Jerry added fallback paths to avoid crashing when some very large texture allocations fail.
- Glenn made semi transparent text support sub-pixel anti-aliasing.
- Glenn fixed text clipping.
- Morris fixed a floating point precision issue in plane splitting (a method used to render 3d transforms with preserve-3d).
- Gankro fixed several shadow rendering issues.
- Martin fixed a bug with nested clips in position-sticky frames.
Notable Gecko changes
- Further WebRender display list building time improvements
- We now build the WebRender text display items directly during text paint instead of a two pass approach where we’d gather the information and then in a second pass construct the WebRender display items.
- Inlining ToRelativeLayoutPoint to further speed up WebRender text display item construction.
- Gankro made us stop hitting the fallback path for most elements in nsFieldSetFrame (in particular those used on GMail).
- Sotaro ensured canvas updates are sent to the compositor on empty transactions.
Mozilla Gfx Team Blog 
I’m very excited to see WebRender being integrated in Gecko, but I’m just a little bit curious as to how it will be integrated. Will Gecko use its own fork? Are Gecko’s needs going to potentially inhibit a more research-oriented approach to its development? I may be wrong, but I would imagine that even after Quantum, Servo and Firefox will still have diverging needs when it comes to the Servo components which were integrated.
Gecko vendors in snapshots of WebRender. The interface between Servo/Gecko and WebRender is fairly minimal, and doesn’t need to change often, so there is still plenty of room for trying different implementation strategies if needed. Servo and Gecko so far have pretty similar needs – after all, as web browsers they both need to accomplish the same tasks :).
Excellent work!