moz://gfx newsletter #53

Bonjour à tous et à toutes, this is episode 53 of your favorite and only Firefox graphics newsletter. From now on instead of peeling through commit logs, I will be simply gathering notes sent to me by the rest of the team. This means the newsletter will be shorter, hopefully a bit less overwhelming with only the juicier bits. It will also give yours-truly more time to fix bugs instead of writing about it.

Lately we have been enabling WebRender for a lot more users. For the first time, WebRender is enabled by default in Nightly for Windows 7 and macOS users with modern GPUs. Today 78% of Nightly users have WebRender enabled, 40% on beta, and 22% on release. Not all of these configurations are ready to ride the trains yet, but the numbers are going to keep going up over the next few releases.

WebRender

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

Ongoing work

  • Part of the team is now focusing on shipping WebRender on some flavors of Linux as well.
  • Worth highlighting also is the ongoing work by Martin Stránský and Robert Mader to switch Firefox on Linux from GLX to EGL. EGL is a more modern and better supported API, it will also let us share more code between Linux and Android.
  • Lee and Jim continue work on WebRender’s software backend. It has had a bunch of correctness improvements, works properly on Windows now and has more performance improvements in the pipeline. It works on all desktop platforms and can be enabled via the pref “gfx.webrender.software”.

Performance

One of the projects that we worked on the last little while has been improving performance on lower-end/older Intel GPUs.

  • Glenn fixed a picture caching issue while scrolling gmail
  • Glenn fixed some over-invalidation on small screen resolutions.
  • Glenn reduced extra invalidation some more.
  • Dzmitry switched WebRender to a different CPU-to-GPU transfer strategy on Intel hardware on Windows. This avoid stalls during rendering.

Some other performance improvements that we made are:

  • Nical reduced CPU usage by re-building the scene a lot less often during scrolling.
  • Nical removed a lot of costly vector reallocation during scene building.
  • Nical reduced the amount of synchronous queries submitted to the X server on Linux, removing a lot of stalls when the GPU busy.
  • Nical landed a series of frame building optimizations.
  • Glenn improved texture cache eviction handling. This means lower memory usage and better performance.
  • Jeff enabled GPU switching for WebRender on Mac in Nightly. Previously WebRender only used the GPU that Firefox was started with. If the GPU was switched Firefox would have very bad performance because we would be drawing with the wrong GPU.
  • Markus finished and preffed on the OS compositor configuration of WR on macOS, which uses CoreAnimation for efficient scrolling.

Driver bugs

  • Dzmitry worked around a driver bug causing visual artifacts in Firefox’s toolbar on Intel Skylake and re-enabled direct composition on these configurations.

Desktop zooming

  • Botond announced on dev-platform that desktop zooming is ready for dogfooding by Nightly users who would like to try it out by flipping the pref.
  • Botond landed a series of patches that re-works how main-thread hit testing accounts for differences between the visual and layout viewports. This fixes a number of scenarios involving the experimental desktop zooming feature (enabled using apz.allow_zooming=true), including allowing scrollbars to be dragged with desktop zooming enabled.
  • Timothy landed support for DirectManipulation preffed off. It allows users to pinch-zoom on touchpads on Windows. It can be enabled by setting apz.windows.use_direct_manipulation=true

10 thoughts on “moz://gfx newsletter #53

  1. Nicolas, I have two questions:
    1. Is there any rough estimate as to when will preliminary Linux precision touchpad support for desktop zooming land in the main branch and therefore be in Nightly builds?
    2. Why is this post numbered fifty-four when the previous one was numbered fifty-two?

    Have a nice day!

    1. 1. I have no idea, sorry. 2. Haha, just me needing a good night of sleep I suppose. I updated the post. Have a nice day as well!

  2. How is the progress of switching from OpenGL/EGL to Vulkan/WSI instead? That’s a lot more modern in comparison and better in practice as well drivers wise.

      1. It’s hard for me to get an impression from it, how far it is or what exactly still remains. Can you summarize it please?

    1. My impression is switching WebRender to Vulkan isn’t a priority. Mozilla’s WebGPU implementation is based on a separate wgpu/gfx-rs/portable Vulkan HAL/magic! Rust stack. Previous mozillagfx newsletters had a section covering this stack, “What’s new in gfx”, I hope no news is good news.

      1. If it’s already switched to gfx-rs, shouldn’t Vulkan be a possible option then? I’d rather avoid dealing with OpenGL driver bugs on Linux. That’s the main reason for me to get Firefox work with Vulkan.

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