WebRender newsletter #27

🎉 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.

Notable WebRender and Gecko changes

  • Bobby implemented a more efficient sizing logic for render targets to save GPU memory.
  • Bobby fixed a crash.
  • Dan prevented enormous box shadows from crashing the renderer.
  • Kats improved the tooling to synchronize between the WebRender and Gecko repositories.
  • Kats and Jamie got WebRender in Firefox for Android to a point where it doesn’t just crash at startup.
  • Kvark fixed the backface visibility bugs.
  • Kvark fixed z-fighting glitch with 3d transforms.
  • Matt fixed some tiled blob image bugs.
  • Andrew landed the first half of the animated image recycling work.
  • Andrew fixed a crash
  • Lee fixed a font leak on Windows.
  • Glenn worked around a clip mask bug with blob images.
  • Glenn landed a series of incremental changes towards picture caching: 1, 2, 3, 4, 5.
  • Emilio implemented proper support for using tiled images as clip masks.
  • Sotaro fixed a texture corruption issue after resuming from sleep on Linux with proprietary nVidia drivers.
  • Sotaro fixed a flickering issue at startup on Windows.

Ongoing work

  • Glenn is making progress towards picture caching.
  • Doug is getting close to completing the document splitting work.
  • Nical is getting a subset of SVG filters to run on the GPU instead of the CPU fallback.
  • Bobby never stops improving memory usage.
  • Matt and Gankro are improving the interaction between blob images and scrolling.
  • Kats is standing up WebRender in Firefox for Android.

Enabling WebRender in Firefox Nightly

  • In about:config set “gfx.webrender.all” to true,
  • restart Firefox.

15 thoughts on “WebRender newsletter #27

    1. You should get WebRender if you set the pref “gfx.webrender.all” to true regardless of whether you have a battery or a low end card.

  1. Hi Nical
    I am not mad I just wanted to know If it will be available for use.
    My laptop runs Windows 10 2018 and… I use Firefox Nightly 65 on it with webrender enabled. I also have Firefox Nightly on Android it says…. unavailable by runtime: WebRender not ready for use on non-e10s Android. Also it says… blocked by env: Has battey. Will webrender ever be ready for use on my configuration. Thank You

    1. I assume on Android it simply isn’t included in the build, I have enabled e10s by setting ‘browser.tabs.remote.autostart’ to ‘true’ and confirmed that multiprocess is then enabled with about:support, but it still says “unavailable by runtime: WebRender not ready for use on non-e10s Android”. You can ignore the “blocked by env: Has battery” as that is only stopping it from being automatically enabled, if you are using the flag to try and enable it then it will ignore the qualification requirements.

    2. It says in the “ongoing work” section this newsletter that Katz is working on making the framework functional to enable webrender in android.

      It’s not implemented in the builds for android yet.

  2. I noticed Picture Caching is blocking a number of bugs and has been a work in progress. I was wondering if you could explain how it works, its development challenges, and its benefits once it’s complete (unless you were saving this for later or aren’t ready yet).

    1. No, for the first release, each glyph is rendered on the cpu and uploaded.
      The work to render the glyphs on the gpu instead is not as well tested yet, so is disabled for now.

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