WebRender newsletter #1

The Quantum Flow and Photon projects have exciting newsletters. The Quantum graphics project (integrating WebRender in Firefox) hasn’t provided a newsletter so far and people have asked for it, so let’s give it a try!

This newsletter will not capture everything that is happening in the project, only some highlights, and some of the terminology might be a bit hard to understand at first for someone not familiar with the internals of Gecko and WebRender. I will try to find the time to write a bit about WebRender’s internals and it will hopefully provide more keys to understanding what’s going on here.

The terms layer-full/layers-free used below refer to the way WebRender is integrated in Gecko. Our first plan was to talk to WebRender using the layers infrastructure in the short term, because it is the simplest approach. This is the “layers-full” integration. Unfortunately the cost of building many layers to transform into WebRender display items is high and we found out that we may not be able to ship WebRender using this strategy. The “layers-free” integration plan is to translate Gecko’s display items into WebRender display items directly without building layers. It is more work but we are getting some encouraging results so far.

Some notable (recent) changes in WebRender

  • Glyph Cache optimizations – Glenn profiled and optimized the glyph cache and made it a lot faster.
  • Texture cache rewrite (issue #1572) – The new cache use pixel buffer objects to transfer images to the GPU (previously used glTexSubImage2D), and does not suffer from fragmentation issues the way the previous one did, and has a better eviction policy.
  • Other text related optimization in the display list serialization.
  • Sub-pixel positioning on Linux.

Some notable (recent) changes in Gecko

  • Clipping in layers free mode (Bug 1386483) – This reuses clips instead of having new ones for every display item. This will reduce the display list processing that happens on the Gecko side as well as the WebRender side. This was one of the big things missing from getting functional parity with current layers-full WebRender.
  • Rounded rectangle clipping in layers free mode (Bug 1370682) – This is a noticeable difference from what we do in layer-full mode. In layer-full mode we currently use mask layers for rounded clipping. Doing this directly with WebRender gives a noticeable performance improvement.

How to get the most exciting WebRender experience today:

Using Firefox nightly, go to about:config and change the following prefs:

  • turn off layers.async-pan-zoom.enabled
  • turn on gfx.webrender.enabled
  • turn on gfx.webrendest.enabled
  • turn on gfx.webrender.layers-free
  • add and turn on gfx.webrender.blob-images
  • if you are on Linux, turn on layers.acceleration.force-enabled

This will give you a peek at the future but beware there are lots of rough edges. Don’t expect the performance of WebRender in Gecko to be representative yet (Probably better to try Servo for that).

All of the integration work is now happening in mozilla-central and bugzilla, WebRender development happens on the servo/webrender github repository.

13 thoughts on “WebRender newsletter #1

    1. The (unsatisfying) answer would be “when it is ready”, and it’s hard to guess when that will be. This project is by far the biggest the graphics team has undertaken since I joined Mozilla (about 6 years ago), hard to foresee the amount of time we’ll spend dealing with unexpected issues and the long tail of platform/driver specific bugs.

  1. Nice, I’ve been curious about WebRender and its integration into Gecko.

    How close to “pure” Servo is the layer-free architecture going to lead Gecko’s WebRender ? It’s probably hard to answer, but are we looking into Servo’s WebRender-related tasks running between 1x and 2x faster, or will the difference be larger ?

    And then, later on, can WebRender’s integration into Gecko ever get closer to pure Servo ?

    1. In the long term, the two should become very close. At first there will probably be some differences between the Gecko and WebRender display lists that will cause us to do some sub-optimal things but I am not sure what these are as I haven’t been involved in the display item conversion work yet. I don’t expect things to make Gecko twice slower than servo (at rendering specifically), especially since display list building is only a part of it.
      If you are talking about the total frame time including layout, JS, etc. the two engines are too different to compare (in the context of WebRender).

      1. Ok thank you, that’s good news :)

        Indeed I was only talking about tasks related to WebRender itself, and the cost of integrating it into Gecko which derive from the need to adapt Gecko and probably WebRender too. So the result has to be a little different than “vanilla” WebRender as part of Servo. If in the end they should become very close, that means Mozilla’s work is not just about plugging in WebRender, but really making it a seamless part of Gecko. That’s very good news.

        Total frame time is another story indeed, lots of other components to account for, though I’ll be curious to see comparisons with Servo once all of Quantum is finished and Servo itself is ready.

  2. Nice, I’ve been curious about WebRender and its integration into Gecko.

    How close to “pure” Servo is the layer-free architecture going to lead Gecko’s WebRender ? It’s probably hard to answer, but are we looking into Servo’s WebRender-related tasks running between 1x and 2x faster, or will the difference be larger ?

    And then, later on, can WebRender’s integration into Gecko ever get closer to pure Servo ?

  3. I tried this on Linux with the latest nightly, and it seems that if I start Firefox with no desktop compositor running, Firefox starts, opens the first window with the first blank tab, and never gets around to restoring the rest of my tabs and windows (and when I quit, it writes out an empty session). The hamburger menu also doesn’t show up when I click it.

    If I start a desktop compositor before running Firefox, it *does* eventually load my tabs. Sometimes it takes half a second for clicks or scroll-wheel scrolls to register, and sometimes the tab crashes, but I guess there’s a reason why it’s not yet the default. :)

    1. The target for WebRender is D3D10-level hardware at the moment. I don’t have the equivalence off hands for OpenGL but I guess it should be around GL 3.x.

  4. Nice, how about assigning a category for this so we can grab the content via category feed RSS? (ya some still use it :P)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s