moz://gfx newsletter #49

By way of introduction, I invite you to read Markus’ excellent post on this blog about CoreAnimation integration yielding substantial improvements in power usage if you haven’t already.

Next steps in this OS compositor integration saga include taking advantage CoreAnimation with WebRender’s picture caching infrastructure (rendering tiles directly into CoreAnimation surfaces), as well as rendering using a similar mechanism on Windows via DirectComposition surfaces. Markus, Glenn and Sotaro are making good progress on all of these fronts.

What’s new in gfx

WebGPU

Kvark landed WebGPU’s infrastructure and initial implementation on Nightly. It can be enabled via the pref “dom.webgpu.enable” in about:config. The functionality is limited to device creation at the moment, with support for Vulkan, D3D12, and Metal.

WebGPU Is a work-in-progress specification for the successor to WebGL 2, exposing a modern API to perform rendering and computation on the GPU.

Various bug fixes and improvements

  • Botond fixed a bug that caused WebExtension popups to render empty with desktop zooming.
  • Botond fixed a WebRender scrolling regression that affected some workflows in Tile Tabs and similar extensions.
  • Botond fixed some Android UX issues related to gesture handling (bug 1570559, bug 1586496).
  • Botond fixed some Android scrolling webcompat issues (bug 1592435, bug 1592902).
  • Botond fixed some more prerequisites for enabling a hiding URL bar in Firefox Preview (bug 1552608, bug 1590582).
  • Markus shared the GL contexts between open windows on Mac.
  • Bob Owen improved the recycling of shared textures.
  • Jonathan Kew fixed a sub-pixel anti-aliasing issue when the text color has some transparency and an emoji is present.
  • Sotaro fixed an issue with DWM, partial present and high-contrast mode on Windows.
  • Andrew allowed image decoders to choose RGBA and BGRA at compile time.
  • Nical Fixed a shutdown crash.
  • Sotaro fixed an issue with partial present and the snapshot mechanism used for reftests.
  • Jonathan Kew enabled a better default fallback font for Mongolian on macOS.
  • Jonathan fixed a whole lot of other font rendering issues.
  • Lee updated Skia to version m79.
  • Jamie avoided using glTexImage3D on android emulator.

What’s new in WebRender

WebRender is a GPU based 2D rendering engine for web written in Rust, currently powering Firefox‘s rendering engine as well as the research web browser servo.

To enable WebRender in Firefox, in the about:config, enable the pref gfx.webrender.all and restart the browser.

WebRender is available as a standalone crate on crates.io (documentation) for use in your own rust projects.

  • Kvark made WebRender use the rounded rectangle fast path more aggressively, improving performance on some sites.
  • Glenn improved the performance of the Direct Composition integration of picture caching by only rebuilding the Direct Composition visual tree if different from last frame and using EGLImage instead of pbuffer for GL to Direct Composition interop.
  • Andrew fixed an issue with pixel snapping and backdrop filters.
  • Bert fixed the capture debugging tool on Windows.
  • Glenn added some debugging infrastructure for picture caching invalidation.
  • Lee fixed an issue with sub-pixel anti-aliasing and ClearType level settings.
  • Nical documented How the data that are passed to the shaders is organized out in GPU memory.
  • Lee improved the performance of text rendering with large sizes and during async zoom.
  • Sotaro made partial updates work with the OS compositor integration on Windows.
  • Jamie disabled picture caching during async zoom when the entire screen is invalidated every frame.
  • Glenn reduced the amount of surface allocations with picture caching.
  • Andrew fixed some pixel snapping issues.
  • Nical reorganized the data that is passed to the vertex shaders to be more consistent and enable better code generation with the multi-brush shader.
  • Nical refactored brush shaders and added the possibility to generate “multi-brush” shaders that support multiple types of primitives in preparation for a more flexible batching infrastructure.
  • Glenn added support for the built-in profiler debug overlays with the OS compositor mode.
  • Markus fixed vibrancy with the OS compositor mode on Mac.
  • Miko refactored display item building so that building function knows the item index beforehand.
  • Glenn fixed a picture caching bug with special pages such as about:support.
  • Glenn implemented CPU-side occlusion culling of picture cache slices to reduce memory usage and overdraw.
  • Jeff added a debugging tool to show when glyphs are re-rasterized.
  • Glenn reduced the work done when a picture cache tile is inside the display port but not currently visible on screen.
  • Nical improved the built-in profiler overlay to show more relevant information in some of the counters and highlight counters outside of their expected ranges.
  • Jamie ensured shader sources are null-terminated even when the source size is provided to work around a shader compiler bug.
  • Martin Stransky implemented dmabuf texture sharing for WebRender.
  • Kris made the screenshot infrastructure used in GeckoView work with WebRender.
  • Nical fixed a gradient rendering bug.
  • Nical improved WebRender’s API documentation.

11 thoughts on “moz://gfx newsletter #49

  1. Thank you for this article. It’s nice christmas reading. I’m looking forward to news about further integration of Direct Composition and Core Animation. Thumb up.

    1. I don’t have an ETA for that at the moment. I also don’t know wayland enough to tell how complicated it will be to build on top of the work done for Windows and Mac compositor integration. Hopefully not too much.

      1. I’m being hopeful as well. The only issue would be the subpar implementation of Wayland in KDE Plasma, but that’s an issue with the desktop environment (for example, when using `GDK_BACKEND=wayland` on Firefox Nightly, whenever I try to resize the window, Firefox freezes up without any chance of recovery, though making Firefox fullscreen does not freeze it until I try to leave fullscreen mode; for what it’s worth, this also happens with KDEnlive). GNOME’s implementation of Wayland is, as far as I can tell, flawless.

        Keep up the good work you guys!

  2. May it be that Linux in general is affected by similar problems as OSX was until recently? Procedures like the tab spinner when reloading a tab e.g. seem to affect performance (and therefore power draw) a lot more on my machine on Linux than on Windows 10.

    Is there a foreseeable future where this is fixable on Linux with WebRender?

    1. AFAIK the first question depends a bit on the setup. There are currently three backends you can use in Firefox (basic, opengl, webrender), on two possible display server protocols (X11 and Wayland). Then there is the question which DE you use and how well that is optimized for things like partial damage, opaque regions etc.

      Lets take two scenarios: you use Ubuntu 19.10 with defaults: Firefox uses the ‘basic’ (software) backend, on X11, on Gnome. Partial damage should be supported here, so maybe things are okayish.
      Another option: you use Fedora 31 (Gnome Wayland session and Firefox Wayland backend) and additionally enabled Webrender. Currently there is no partial damage support, opaque regions are only used since 71 (but not always [1]). As a result, the spinner makes FF update the whole Window (therefore potentially a big part of the screen) and Gnome is not always as efficient as it could be handling this -> likely a big power impact.

      So now on to the second question: Yes absolutely. That’s what the comment above (https://mozillagfx.wordpress.com/2019/12/05/moz-gfx-newsletter-49/#comment-19562) is about. Webrender in combination, or actually integration, with Wayland should be able to make FF on Linux as efficient on Linux as it is/will be on Win/MacOS, if not better (if there are any major obstacles: it is OS, we can change it!). Further more there is quite a lot of work happening on Gnome to optimize more for this (e.g. [2][3]). I personally see good chances this will be archived in 2020, lets see.

      1: https://bugzilla.mozilla.org/show_bug.cgi?id=1602309
      2: https://gitlab.gnome.org/GNOME/mutter/merge_requests/867
      3: https://gitlab.gnome.org/GNOME/mutter/merge_requests/918

  3. Hi Nical
    Will webrender ever be fixed for GPU adreno308? The GPU for my lg Phoenix plus andriod phone os9. Because as of now when I use Google groups a get a blank white screen. Im writing this comment on my…. Kindle Fire HD8 os lollipop andriod tablet where is no issues with having webrender enabled. And the GPU for my tablet is…. malit-720.

    1. Hi Nical
      Will webrender ever be fixed for GPU adreno308? The GPU for my lg Phoenix plus andriod phone os9. Because as of now when I use Google groups a get a blank white screen. Im writing this comment on my…. Kindle Fire HD8 os lollipop andriod tablet where is no issues with having webrender enabled. And the GPU for my tablet is…. malit-720.
      https://groups.google.com/forum/m/#!forum/fenix-nightly

  4. Now that WebRender is more or less deployed in all recent Firefox versions, is there some plan to implement hardware acceleration for video decoding and encoding through VAAPI on Linux?

    I remember reading somewhere, that switching to WebRender was the main blocker for that (or rather a dependency, to avoid doing double work with different compositing pipeline).

    1. We are not quite there yet. Most Firefox users don’t have WebRender enabled yet. I’m not up to speed with the plans for video decoding on Linux. I suspect that part of the challenge is in how video frame textures are passed from the decoding process to the rendering process, which is affected by whether Wayland or X11 is used under the hood. I know that Martin Stransky has been putting a lot of work with the end goal of imporving video playback performance (under Wayland).

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