Firefox Is Making WebRender The Default Rendering Engine On Linux This Month And There Is A Facelift Coming In May

From LinuxReviews
Jump to navigationJump to search
Firefox-space-icon.png

The Firefox web browser is finally making the long-anticipated WebRender rendering engine the default on GNU/Linux when Firefox 88 is released later this month. WebRender, developed as apart of the "Quantum" project, has been optionally available since Firefox 67. It's not at all impressive performance-wise unless you manually flip the new secret performance-boosting switch. That new switch happens to also make enabling VAAPI hardware video decoding easier. More is planned, a improved, or perhaps just slightly different, interface will arrive when Firefox 89 is released towards the end of May.

written by 윤채경 (Yoon Chae-kyung)  2021-04-06 - last edited 2021-04-16. © CC BY

Firefox-89.0a1.jpg
Mozilla Firefox 89.0a1 ("Nightly").

WebRender is a not so brand new rendering engine Mozilla begun developing as part of Mozilla's Servo Project in 2012. Mozilla started implementing it in Mozilla Firefox as part of their "Quantum" project in 2016. Servo itself was later taken over by the Linux Foundation. Servo, and WebRender, is written entirely in the Rust programming language.

Mozilla made the WebRender rendering engine from Servo optionally available when Firefox 67 was released on May 21st, 2019. It has been possible to turn it on by flipping gfx.webrender.all to true in the special configuration page you can get typing about:config in the address bar since then, but it has so far not been a default. That will change when Firefox 88 is released on April 20th.

No-No Turning It off

WebRender will be enabled for all Linux users in a slightly odd way when Firefox 88 is released.

Firefox 88b7 (beta) shows Compositing: WebRender in about:support and so does Firefox Nightly (currently 89.0a1) - yet both have gfx.webrender.all and gfx.webrender.enabled set to false in about:config by default (just like earlier releases).

There does not appear to be any way to turn it off. That is a bit of a shame because it means that GNU/Linux users no longer have the option of enabling the older OpenGL renderer by flipping layers.acceleration.force-enabled to true. That switch does absolutely nothing in Firefox 88+. The OpenGL renderer was never made a default on GNU/Linux even though it was much better than the "Basic" rendering Firefox has defaulted to on GNU/Linux until now, so it is hard to guess if they intentionally removed it as an option or if it is just a unfortunate side-effect of they way they are force-enabling WebRender.

Better Than Basic, But Not Overall Impressive

... unless you happen to know that you should type about:config into the address bar, search for egl.force-enabled in the interface you get there and flip that shiny new switch to true. It is new to Firefox 88+ (though it can be enabled by setting the environmental variable MOZ_X11_EGL=1 in Firefox 87 and a few earlier versions). A restart is required (you can type about:restartRequired into the address bar) to make it take effect. about:support will tell you if it is enabled.

The difference between the new default-enabled WebRender and WebRender performance you can unleash by flipping the magic egl.force-enabled switch is, as you will see in the benchmark numbers below, quite significant.

Basemark Web 3.0 (higher is better)
Intel i7-5500U, 1080p, Linux 5.11.11, Mesa 21.0.1
Basemark Web 3.0 (higher is better)
AMD Ryzen 2600 / RX 470, 1440p, Linux 5.11.11, Mesa 21.0.1

How WebRender performs seems to be very dependent on what hardware it has available. It scores laughably low in the Basemark Web 3.0 benchmark by default on our Intel test laptop. The results are far worse than what they are with both the old "Basic" rendering and the old "OpenGL" rendering on that machine. Enabling EGL helps a little, but not much. The AMD box paints a different picture; WebRender is marginally better than Basic and marginally worse than OpenGL by default and much faster when EGL is enabled.

The "new" WebRender rendering engine, as well as Mozilla Firefox in general, pales in comparison to Chromium and the in every way far superior South Korean Chromium-based NAVER whale web browser in this particular benchmark - unless WebRender+EGL is used on a computer with a AMD GPU. That particular combination allows Firefox to go from being a clear underdog to a contender. That is, oddly, not the case on the Intel machine.

Mozilla Firefox makes up for its shortcomings in the Basemark Web benchmark with strong results in the WebXPRT 3 benchmark by the Intel-front Principled Technologies.

WebXPRT 3 (higher is better)
Intel i7-5500U, Linux 5.11.11, Mesa 21.0.1
WebXPRT 3 (higher is better)
AMD Ryzen 2600 / RX 470, Linux 5.11.11, Mesa 21.0.1

WebRender doesn't help in the WebXPRT 3 test, but it doesn't hurt either, and Mozilla Firefox holds onto the long-held lead it has had in this benchmark. Enabling EGL doesn't make a difference in this not-graphics intensive benchmark.

WebGL is another story. WebRender increases WebGL performance significantly, somewhat depending on the hardware, if you manually enable EGL with the magic EGL switch.

Unity WebGL 2018 (higher is better)
Intel i7-5500U, Linux 5.11.11, Mesa 21.0.1
Unity WebGL 2018 (higher is better)
AMD Ryzen 2600 / RX 470, Linux 5.11.11, Mesa 21.0.1

The WebRender rendering engine is by default, overall, neither a deal-breaker or a deal-maker. It is not very impressive, but it is also not horrible. That changes if you manually tweak it by enabling egl.force-enabled, the massive performance boost it gives WebGL and graphics-intensive web applications is very apparent in the Unity WebGL 2018 benchmark.

A New And Simpler Path To Hardware Video Encoding

Firefox-88.0b7-with-egl-force-enabled.jpg
Mozilla Firefox 88.0 beta 7 with EGL force-enabled.

Mozilla has made life easier for GNU/Linux users in one perhaps important way in Firefox 88: Enabling hardware video decoding with VAAPI has become slightly simpler.

You can check if your GNU/Linux machine supports hardware video decoding by typing vainfo (available in a package named libva-utils or similar in case you don't have it). It is much more likely than not that your machine can do hardware video decoding.

Enabling it in earlier versions of Firefox was a bit of a pain. You would have to either enable OpenGL rendering or enable WebRender and launch Firefox with the MOZ_X11_EGL=1 environment variable set. Firefox 88 has a brand new gfx.x11-egl.force-enabled setting in about:config you can use instead. It will, as a nice side-effect, also make WebRenderer a lot faster depending on what hardware you have.

You will also have to set media.ffmpeg.vaapi.enabled to true and, additionally, also set media.ffvpx.enabled to false if your hardware supports VP8 and VP9 hardware decoding. media.ffmpeg.vaapi.enabled does nothing unless EGL is enabled, which is why it is so convenient that Firefox 88 gets a about:config flag for turning it on.

Verifying that VAAPI hardware video decoding actually works in Firefox isn't all that easy. The trick is to start it from a terminal with MOZ_LOG="PlatformDecoderModule:5" as in something like:

MOZ_LOG="PlatformDecoderModule:5" firefox-88/firefox -P ProfileManager

Running Firefox like that won't produce anything even remotely interesting in your terminal until you start playing a video. It will, at that point, start spewing out a continuous stream of debug-output. That stream will either contain:

[Child 4068926: MediaPDecoder #3]: D/PlatformDecoderModule DMABufSurfaceWrapper: VAAPI releasing dmabuf surface UID = 6
[Child 4068926: MediaPDecoder #3]: D/PlatformDecoderModule DMABUF/VA-API Got one frame output with pts=966667dts=1000000 duration=33333 opaque=-9223372036854775808
[Child 4068926: MediaPDecoder #3]: D/PlatformDecoderModule DMABufSurfaceWrapper: VAAPI releasing dmabuf surface UID = 6

or not contain any mention of VA-API at all. VA-API is obviously enabled if Firefox tells you all about how it is being used.

The Proton Facelift

Firefox-89-with-and-without-proton.jpg
Mozilla Firefox 89 with and without browser.proton.enabled. On your left: The old. On your right: The New.

The Firefox developers have been working on a "new design" called Firefox Proton. It is sort-of available by a about:config switch called browser.proton.enabled in Firefox 87, except that the switch does absolutely nothing in Firefox 87 and 88.0b7. It does do something in Firefox 89.0a1 (currently only released as "Nightly"). Mozilla plans on enabling it by default when Firefox 89 is released on May 18th, 2021. This months release, scheduled for April 20th, will not have Proton enabled.

You can try the new "Proton" look by acquiring a "Nightly" Firefox build from mozilla.org/en-US/firefox/channel/desktop/ and enabling browser.proton.enabled. You will have to re-start Firefox after you enable browser.proton.enabled, it does not take effect until you do.

The difference, in Firefox 89.0a1 where there actually is one, is not all that huge or apparent. The pop-out menu is slightly reorganized, and the toolbar looks slightly different. That's about it.

Firefox-89-with-and-without-proton-2.jpg
The Firefox toolbar does look slightly different with the new "Proton" look enabled. The difference isn't huge, but it's there.

Mozilla Firefox 88, with WebRender as the default and seemingly only available rendering engine, is scheduled to be released on April 20th. Firefox 89, with the new "Proton" look, is scheduled to be released a month later on May 18th. You can download 88 as a beta or 89 as "nightly" from www.mozilla.org/en-US/firefox/channel/desktop/ if you want to try these upcoming Mozilla Firefox versions today.


The Russians are seemingly unaware of these Mozilla Firefox developments.

4.00
(4 votes)


avatar

Chaekyung

10 months ago
Score 1++
There's no rivalry. opennet sent us 14% of our non-search engine traffic last month. We have used some of their articles as a basis for ours in the past. We link to them in those cases. I added that one-liner to the bottom of a few articles based on our own benchmarks and research this week just in case Максиму Чиркову, who runs opennet, feels like translating and use them. opennet uses creative commons cc-by for their articles, just like we do. This site isn't in Russian so it's all good when they use our articles and images (though it is slightly annoying that they tend to hot-link, not re-upload, our videos, that tends to consume a whole lot of bandwidth).
avatar

Intgr

10 months ago
Score 0++

"It did not originate at Mozilla, WebRender was originally developed by the Linux Foundation-funded Servo web engine project."

Sounds like some Mozilla-hating revisionism at work here. No, Servo *was* started and mostly developed by Mozilla. Linux Foundation only took over the project in 2020. I don't think any money of Linux Foundation itself goes towards employing Servo developers?
avatar

WaiLin

10 months ago
Score 0++

I've changed that and added a link to https://rese...rvo-engines/ where it says Mozilla started it in 2012. https://servo.org/ says "Servo Project a Series of LF Projects, LLC", it kind of sounds like LF started and developed it on all their own if you just look at that one.

You can fix more than spelling errors if you want to, btw. There is nothing wrong with fixing factual errors. If the text is plain wrong then it's plain wrong, just like a typographical error.
avatar

Chaekyung

9 months ago
Score 0++
Setting gfx.webrender.force-disabled brought back "OpenGL" rendering with layers.acceleration.force-enabled set to true and the utterly slow "Basic" rendering without it. It was probably a bit naive to think that Firefox that setting gfx.webrender.enabled to false would be the right way to disable it because that would actually make sense and be expected behavior.
Add your comment
LinuxReviews welcomes all comments. If you do not want to be anonymous, register or log in. It is free.