WebRender newsletter #42

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.

What’s everyone working on?

  • Glenn has been investigating WebRender’s performance on Android ARM Mali devices. There seem to be some reasonable overlap between optimizations affecting Intel integrated GPUs and Mobile GPUs which is good news. This investigation led to a few performance optimizations such as a fast path generating clip masks in the common cases reducing the number of fragment shader instructions, and some changes to the way data is provided to clip render tasks to use pixel local storage instead of the render task data texture.

  • Kvark made a few refactorings improving the internation code as well as framebuffer coordinates and document origin semantics. Kvark also improved plane-splitting accuracy and the way GL driver errors are reported.
    Kvark also extracted a useful bit of WebRender into the copyless crate. This crate makes it possible to push large structures into standard vectors and hash maps in a way that llvm is better able to optimize than when using, says, Vec::push. This lets the large values get initialized directly in the container’s allocated memory without emitting extra memcpys.

  • Kats has fixed a number of scrolling related bugs, and is improving the automatic synchronization of WebRender’s code between the mozilla-central and github repositories.

  • Nical is investigating optimizations of the render task tree (with the idea of turning it into a graph rather than a tree strictly speaking). Currently WebRender does not provide a way for the output of a render task to be read by several other render tasks. In other words, if an element has a dozen shadows, we currently re-compute the blur for that element a dozen times. There are ongoing experiments with various render graph scheduling strategies in a separate repository and some of the findings from these experiments are being ported to WebRender.

  • Sotaro has landed a series of improvements around the way we handle cross-process texture sharing and how GL contexts are managed.

  • Timothy is working on a GPU implementation of the component transfer SVG filter. Avoiding the CPU fallback for this particular filter is important because of its use in Google docs.

  • Jeff has been doing a lot WebRender bug triage and profiling. He also fixed a very bad interaction between tiled blob images and filters which was causing the whole filtered area to be re-rendered from scratch for tile.

  • Doug continues his work on document splitting. A large part of it has already been reviewed.

Stickers!

Jessie got some glitchy gfx team stickers printed. It’s not a WebRender news per se, but I didn’t want to pass on an occasion to put a fun picture on the blog.

gfx-sticker

I originally made this (absolutely unofficial) logo to decorate the blog by simply flipping random bits in a png image of the Firefox Nightly logo. I recently re-did the logo in SVG using Inkscape to get a high enough resolution for the stickers.

Enabling WebRender in Firefox Nightly

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)

9 thoughts on “WebRender newsletter #42

  1. No mention of Firefox 67 entering beta phase, so I take it that ship has sailed and we won’t be seeing webrender outside of nightly for a few more releases still?

    1. WebRender does not discriminate support based upon whether you’re using a laptop or a desktop, but whether the GPU used is stable enough with WebRender. That is to say, it depends on whether you’re using Intel or AMD or Nvidia graphics and which models of GPUs as well (although you can enable WebRender by force in Firefox Nightly using the instruction that Nical provides in each post).

  2. Is there any ETA for WebRender to be ready for Linux builds? While I’m using it successfully with Firefox beta (amdgpu / radeonsi), it’s unreleased status seems to be the blocker for work on GPU accelerated video encoding / decoding. I.e. it’s not being worked on, until WebRender switch will be complete. That basically makes WebRTC on laptops running Linux to perform very poorly. So I wish WebRender to succeed soon :)

Leave a Reply to Nical Cancel 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