WebRender newsletter #27

By Nical

🎉 WebRender is in beta 🎉! There are still a number of blocking bugs so WebRender will stay on beta for a few trains until it has received enough polish to hit the release population. This is an important milestone for everyone working on the project and the main piece of news outside of the bullet points below.

I’m increasingly  running out of ideas to write intros without repeating the same thing each week. So instead I’ll start the next few newsletter with a piece of WebRender history. Here is one:

Towards the beginning, WebRender’s overall architecture really felt centered around attempt at answering the question “Can we implement CSS rendering logic directly on the GPU?”. By that I mean that WebRender had a collection of shaders that very closely matched CSS properties. For example a single image shader was able to handle all of the image and background-image properties, and a single border shader was able to do all of the different border styles, parameters being provided in layout space instead of device space. This maybe doesn’t sound like much, but for someone who’s been used to seeing layers upon layers of abstractions between the output of layout and the final pieces of graphics code that writes into the window, this idea of implementing the CSS specification directly into shaders in a fairly straightforward way was quite remarkable and novel. In today’s WebRender the shader system isn’t as close to a verbatim implementation of CSS specifications as it used to be. A lot of this “low level CSS” vibe remains but we also split and combine shaders in ways that better take advantage of the characteristics of modern GPUs.

To me, this ability to solve specific web rendering challenges in the high and low level layers alike without having to conform to old rendering models is one of WebRender’s greatest strengths.