WebRender newsletter #16

Greetings! 16th newsletter inbound, with some exciting fixes. Oh yeah, fixes again and again, and spoiler alert: this will remain the main topic for a little while.
So what’s exciting about it this time around? For one, Heftig, Martin Stránský and Snorp figured out what was causing rendering to be so broken with nvidia GPUs on Linux (and fixed it). The problem was that when creating a GLX visual, Gdk by default tries to select one that does not have a depth buffer. However, WebRender relies on the depth buffer for rendering opaque primitives.
The other fix that I am particularly excited about is brought to you by Kvark, who finally ended the content flickering saga on Windows after a series of fixes and workarounds in our own code and upstream in ANGLE.

Notable WebRender changes

  • Simon added support for rendering with ANGLE in wrench on Windows. This will let us run tests in a configuration that better matches what users run.
  • Kvark fixed a division by zero in the brush_blend shader.
  • Glenn fixed some box-shadow artifacts.
  • Lee fixed the way we clear font data when shutting down.
  • Glenn avoided attempting to render a scene if the requested window dimension are unreasonably large.
  • Nical avoided re-buiding the scene when updating dynamic properties (it had already been done by Glenn, but accidentally backed out).
  • Glenn refactored the way pictures and brushes are stored to allow more flexibility.
  • Kats and Nical updated the tidy CI script, and fixed an avalanche of followup issues (2), (3), (4).
  • Martin simplified the clipping API.
  • Glenn fixed text-shadow primitives during batch merging.
  • Glenn ported intermediate blits to the brush_image shader.
  • Nical decoupled the tiled image decomposition from the scene building code (in preparation for moving it to the frame building phase).
  • Kvark refactored the shader management code.
  • Glenn ported blurs to use brush_image instead of the composite shader.
  • Simon implemented an example that uses DirectComposition.
  • Martin fixed a clipping issue in blurred and shadowed text.
  • Kvark worked around an ANGLE bug after backing out another attempt at working around the same dreaded ANGLE flickering bug.
  • Jeff avoided performing divisons and modulos on unsigned integers in the shaders.
  • Glenn optimized the brush_image shader.
  • Glenn changed box-shadow to be a clip source instead of a picture, providing some simplications and better batching.
  • Glenn reduced the number of clip store allocations.
  • Martin removed inversed matrix computations from the shaders.
  • Kvark fixed a bug with zero-sized render tasks.

Notable Gecko changes

  • Snorp, Heftig and Martin Stránský fixed broken rendering with nvidia graphics cards on Linux. WebRender is now usable with nvidia GPUs on Linux.
  • Kvark fixed flickering issues with ANGLE on Windows.
  • Sotaro fixed a crash, and another one.
  • Andrew made background SVGs use blob images instead of the basic layer manager fallback, yielding nice perf imporvements.
  • Nical made gradients rely on WebRender’s pixel snapping instead of snapping incorrectly during dsiplay list building.
  • Sotaro fixed a bug when moving a tab containing a canvas to a different window.
  • Sotaro fixed a jiggling issue on WIndows when resizing the browser window.
  • Nical fixed a race condition in the frame throttling logic causing windows to not paint intermittently.
  • Andrew avoided using the fallback logic for images during decoding.
  • Sotaro fixed an ffi bug causing images to not render on 32bit Windows.
  • Jeff simplified the memory management of WebRenderUserData.

Enabling WebRender in Firefox Nightly

In about:config, just set “gfx.webrender.all” to true and restart the browser. No need to toggle any other prefs.

Note that WebRender can only be enabled in Firefox Nightly. We will make it possible to enable it on other release channels as soon as we consider it stable enough to reach a broader audience.

15 thoughts on “WebRender newsletter #16

  1. Does this mean you’re basically stabilizing for a first release and further performance work will only come after that? I think WebRender performance is still subpar on slower machines, both CPU and GPU wise.

  2. Yes, and the first release specifically targets a restricted set of configurations for which WebRender currently performs very well. After this release ships, we’ll progressively look into more configurations including various flavors of low end laptops and phones.

  3. So do you still see potential in better WebRender performance overall or will this be more about working around driver/device specific issues?

    Thanks for always answering comments, it’s very interesting.

    1. There is a mountain of performance plans that we are holding off so that we can ship something as soon as possible, and will get to later. I suspect there will also (unfortunately for us because it’s not fun) be a some amount of driver-pecific work (or rather family-of-drivers specific).

    1. There are plenty of features to add to WebRender itself (SVG rendering for example) even after we ship the first version of WebRender. Improvements to make over what’s already there, stabilizing/fixing, etc. Beyond that it’s too far in the future for me to be able to predict what the priorities will be for the gfx team.
      Currently, layout and js tend to be bottlenecks on heavy web pages and I am sure the layout and js teams are working their magic to improve there.

  4. It’s great to see how far WebRender is coming! On Windows 10 bootcamp with a 2015 Mac Pro (Radeon R9 M370X) and Nightly 61.0a1 (2018-03-21) (64-bit) I see a lot of artifacts using WebRender in the following demo: https://keithclark.co.uk/labs/css-fps/nojs/

    My understanding is the demo is using a bunch of divs, css transforms, animations, and background images with different blend modes so seems like a good stress test for what WebRender should be able to support right now.

    1. I am curious about that too, Nigthly 61.0a1 (2018-04-06) (64-bit) and I confirm the same problems on Nvidia are still the same as before the patch.

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