WebRender newsletter #45

Hi there! I first published this newsletter episode on May 21st and hitting the publish button at the same time as Jessie who wrote an excellent announcement post about WebRender on the stable channel. We decided to unpublish the newsletter for a couple of days to avoid shadowing the other post.

WebRender is a GPU based 2D rendering engine for web written in Rust, currently powering Mozilla’s research web browser servo and on its way to becoming Firefox‘s rendering engine.

🎉 WebRender enabled by default for a subset of users on stable 🎉

Firefox users on the stable channel are starting to use WebRender without opting into it manually.
This is a huge milestone for everyone involved! The initial target configuration is Windows 10 with nvidia desktop GPUs and recent enough drivers. A very specific and small set of users for sure, and this is so that we can progressively roll out this massive change to Firefox’s graphics engine and appropriately react to the bugs that went unnoticed during all these months of testing and polish (and I am sure there will be). On the nightly channel, we’ve already started enabling WebRender by default on some AMD and Intel configurations on Windows and Linux.

Congratulations and big thanks to everyone who helped pushing WebRender forward, mozilla staff and volunteers alike. In particular, I would like to highlight the tremendous amount help provided by volunteer contributors Darkspirit and Alice0775 White in filing, reproducing and triaging bugs.

Bug triage is an often underapreciated, yet absolutely vital part of the process of making Firefox. Without it developers would not know about important bugs that need fixing. It is crucial to our ability to see and react to problems in the wild and impacts priorities and other decision making. Bug Triage is time consuming and requires a lot of knowledge about the project. So once again, many thanks to Alice0775 White, Darkspirit and many other volunteers who’s help and impact on the project is really appreciated.

What’s new in WebRender

  • Glenn landed a number of changes towards generating separate batches per dirty region. The goal is to improve the performance of incremental updates.
  • Glenn fixed external scroll offsets for perspective elements.
  • Kvark fixed a backfrace-visibility issue.
  • Kvark fixed a texture cache reallocation crash.
  • Kvark fixed a transform flattening bug.
  • Kvark added support for using the KHR_blend_equation_advanced GL extension for mix-blend modes.
  • Kats added support for WebRender’s builtin debugging and profiling features on Android.
  • Doug fixed a number of document splitting bugs.
  • Nical finished turning the render task tree into a more powerful render task graph, and integrated the debug visualization into frame captures.
  • On top of this Nical started implementing render graph optimizations for items with many shadows.
  • Nical increased the amount of blob tiles that are rendered asynchronously.
  • Gankro landed the refactoring to how we represent webrender display items, reducing the size of lots of items, eliminating lots of meaningless states, and making it easier to read webrender captures.
  • Gankro got cbindgen to work with rust 2018 extern crate idioms, unlocking the ability for us to bump webrender and other gecko crates to Rust 2018.
  • Andrew improved pixel snapping.
  • Andrew fixed a crash caused by primitives with empty clips in some situations.
  • Jamie is improving glyph zooming on Android.
  • Jamie fixed a border rendering bug.
  • Jeff fixed a number of bugs with “clipped drawtargets”, a way to better represent the work for tiled blob images and deduplicate work.
  • Jeff and Nical reduced memory allocation overhead in during blob image rasterization.
  • Sotaro landed a lot of improvements to the texture sharing code.
  • Sotaro enabled the shader cache on android.
  • Lee reduced lock contention when rendering text on Windows.
  • Lee improved dual-source blending.
  • Miko landed many improvements to displaylist building performance.

Enabling WebRender manually

In about:config, enable the pref gfx.webrender.all 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.

Using WebRender in a Rust project

WebRender is available as a standalone crate on crates.io (documentation)

14 thoughts on “WebRender newsletter #45

  1. Thank you very much for posting these newsletters. Keep going! I like reading of these interesting things about WebRender very much because I’m big fan of it. And also big congratulation for releasing of WebRender in Fx67.
    BTW. I don’t want to be pedantic but maybe you’ll find it useful. I found some typos :-) :
    “WebRender enabled by default for a subset of >>users<>unnioticed<>imapact<< on the project.."

    1. I’m sorry, bad formatting:
      “WebRender enabled by default for a subset of users users on stable”
      “..react to the bugs that went unnioticed..”
      “..who’s help and imapact on the project..”

  2. Nical just some constructive feedback here: I think yous are being too conservative with the WebRender rollout testing! I’ve been using WebRender since 67 beta on an Intel Kaby Lake 620 laptop and I’ve not noticed any issues at all. In fact, Firefox is noticeably faster and a little bit smoother too. WebRender is ready for wider testing! v68 beta should include Windows 10 desktops with Intel graphics too, or at least 50% of the Windows 10 desktops with Intel graphics. Honestly, almost everyone on Windows 10 should get WebRender for v70 stable, laptops included. Yous have done an amazing job, thank you :)

    1. Thanks for the compliments. We’ve had some rather catstrophic experiences in the past while doing big rollouts, caused by unexpected driver bugs and other things that are hard to predict and test for.

      When Firefox breaks suddenly for a very large amount of users it does a lot of damage, and to be honnest, perhaps you are right, it could be that we are being too conservative about this. But we would only know for sure if things go very bad and this time around (due to the scope and risks of the project) we chose to be very cautious.

      It does not change our ambition to move all users to out new rendering architecture eventually. In the mean time, enthousiastic users such as yourself can enable it manually and I appreciate hearing that things are working well on your configuration (We can’t take this for granted as there is a limitied amount of hardware and websites that we can possibly test for internally).

      1. Right now WebRender is enabled for Linux users on Intel integrated GPUs with Mesa 18.2 or newer on Nightly if their screen resolution is 3440×1440 or less. A nice next step would be to enable it for AMD/Nvidia users too, and maybe enable it for Beta users also. The biggest risk seems to be rolling out to users of FF stable, so rolling it out to desktop Linux users on Nightly and Beta would be IMO an excellent next step.

      2. Totally share you pain, and agree on being very careful Nical!

        Just our of curiosity I force-enabled WebRender on my MacBook Pro (2016) and I’m delighted as I never noticed a problem since FF 67 came out!

        I have to stress that I’m a very heavy FF user (since forever actually) so I literally access every type of web app/web site and I usually keep tens of tabs open for days (I use Chrome but on the side and mainly for development work).

        I’d be happy to say something more about WebRender speed but I have no hard numbers and I may be biased toward saying that I feel FF feels faster to me, but I’ll refrain from it… :)

  3. Hi Nical — can you point us to an existing SxS comparison (or create one) of Firefox with and without WebRender for the top-25 sites that you already use for your testing? This would be a great way for folks to visually compare the two rendering engines and be amazed at the progress / improvements that the team has made.


    1. +1 on this – I remember Edge had some in-browser demos when they showed off their GPU-accelerated rendering, but I’ve struggled to find sites that really allow me to show the difference Firefox makes.

  4. With WebRender slowing becoming adopted, is Mozilla re-considering how to handle zoom on desktop/tablets? Currently, font-sizes increase and images change size, but it’s not quite the same as zooming on a page, the way Safari on iOS pioneered and now both Edge and Chrome mimic on desktop?

    It makes using a PC tablet so much nicer and seems a much easier thing to implement now rendering occurs in a clipped, GPU-accelerated window.

  5. Please if have time don’t give up on the newsletters. Because I’m a fan of both the newsletters and WebRender. I use WebRendre on my Windows 10 1903 laptop and both my android phone and tablet. On both my phone and tablet I use Firefox Preview and… I switch to having Firefox Nightly as my secondary browser. And because just doing a web search to see if I could have WebRender on my tablet and….. at the time I found out on reddit… if I wanted WebRender on android I would need to install Firefox reference browser. So I use my tablet more, then my phone, more space, and at the time when I added WebRender Firefox reference browser was on Google play and Firefox Preview was not.

  6. Please if you have time don’t give up on the newsletters. Because I’m a fan of both the newsletters and WebRender. And I forgot to add… on my Andriod tablet and phone when I use WebRendre… I gave up add-ons and themes which I use on my Firefox nightly for windows and Andriod.

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