Firefox Nightly 63: Mozilla runs WebRender study
WebRender is a new technology that Mozilla plans to integrate in the Firefox web browser. A milestone has been reached recently as WebRender has been enabled for part of the Firefox Nightly population.
WebRender is a Servo component written in Rust that Mozilla plans to integrate into Firefox. The main idea behind WebRender is that the graphics processing unit (GPU) is used to render web content instead of the processor which has been used traditionally for that.
WebRender will replace the compositor that Gecko uses currently in Firefox. The switch from using the CPU to do the heavy lifting in regards to rendering to the GPU should improve performance of the entire process significantly.
While users should not expect major performance boosts right now in Firefox Nightly,Â Mozilla's aim is to improve Firefox's rendering performance significantly in the long run.
Mozilla decided to run a Shield study to test WebRender under specific criteria in Firefox Nightly. Shield studies are run to gather data, in this case how certain metrics such as crashes change on WebRender versions of Firefox compared to Firefox versions without WebRender.
The study runs on Windows 10 devices with Nvidia GPUs only and the latest version of Firefox Nightly is required as well as it won't be run on other Firefox channels such as Beta.
Mozilla will select 50% of the Firefox population that meets the test criteria and enable WebRender on those systems; the remaining 50% are the control group which means that WebRender won't be enabled on those devices.
The main goal of the study is to make sure that WebRender runs within acceptable parameters when compared to the control group. Mozilla wants to make sure that regressions and crashes stay within a 5% to 10% limit.
Mozilla plans to set the preference gfx.webrender.all.qualified on eligible systems to true to enable WebRender on those systems. You can change the preference at any time, for instance when you notice rendering issues, crashes, or other issues that are caused by WebRender.
Mozilla collects issues on [email protected], and has listed some already. Users may notice higher CPU usage with WebRender enabled on YouTube, FTS drops on WebGL demo websites with the feature enabled, and that "specific images entirely coded in HTML & CSS are not correctly rendered".
The study will run for two weeks after which it ends. Data is analyzed afterward and Mozilla's next steps will be based on that analysis. (via SÃ¶ren)
WebRender is a promising new feature of Firefox that is currently in development and testing phase. Mozilla wants to make sure that WebRender improves the rendering and does not cause regressions before it enables it for a larger part of the Firefox population or other channels.
Now You: What's your take on WebRender?
I like the idea. A lot. GPUs are made to do lots of small tasks at once. CPUs on the other and can do as many tasks as cores are available. Anything more and prioritization comes into place. Will give this a try later today.
If it’ll help them to make firefox more html5 compliant, more secure and fastest : it’s a good idea, in other case : not a top priority
It does give a quite significant speed boost, especially on graphically intensive webpages.
Webstandards-compliance and security are not at the heart of the project, but it being written in Rust means that a whole row of security vulnerabilities are not possible (unless a developer is actively being stupid, not just neglectful).
Rust also abstracts some more complexity away than C++ and isn’t as overloaded with historically added features, so in the long run, there should be less general bugs in the new code, too, which will lead to better webstandards-compliance.
This apply for Android?
This particular study is not being done on Android. Future studies however might, and WebRender is definitely coming to Android at some point.
You can already manually enable it on Android Firefox Nightly and it does show its effect.
It currently still has some bigger bugs, though, resulting in pages sometimes not being rendered anymore at all, until you force stop and restart Firefox. So, right at the moment, I wouldn’t recommend it. Might be better again, in a week or two, though.
“What’s your take on WebRender?”
Sounds fine, as long as Firefox will still run on machines that don’t have a suitable GPU. Since increasing browser speed is not something that is meaningful to me, this doesn’t particular excite me, but I see no harm in it.
> Sounds fine, as long as Firefox will still run on machines that donâ€™t have a suitable GPU.
There will always be a fallback when WebRender won’t be able to run.
I’ll probably be able to recover the sweet sound of my graphic card’s ventilator running at full speed, what a bonheur.
Firefox has already increased this speed. But its still behind chrome in latency with websites that carry many objects.
I just hope one day firefox will blow chrome out the water.
“I just hope one day firefox will blow chrome out the water.”
Firefox already blows Chrome out of the water in many categories…
“Browser startup” is much faster in FF when measured till ALL extensions are loaded AND working with FF 35% faster. FF 2.0s vs Chrome 2.7s. Browsers are using a lot of the same extensions: uBO, No-Script Suite Lite, Privacy Possum, Tampermonkey and Stylus. And it’s not uncommon for Chrome to fail to finish loading extensions at startup.
“Memory use” is much better in FF. With 12 tabs open Chrome used 16% more memory (1.23GB) than my FF install (1.11GB) even though my FF install is using 6 content processes instead of the default of 4 and has a bigger than default memory cache size. Not a big difference in memory used (16%) but I can easily make FF use less. My 2nd Firefox profile, with mostly default settings, other than security and privacy settings, and with 3 active extensions used 757MB of memory. Chrome used 65% more memory than my 2nd profile. Wow… that’s… embarrassing! LoL. Waterfox was at 1.03GB (1057MB) using the default of 1 content process. Not what I expected.
With “graphics rendering” FF has a significant advantage on graphics heavy pages. And FF makes much better use of my graphics card compared to Chromium browsers, without webrender enabled. Browsers know when a graphics card is installed and the fact that Chrome won’t make better use of my card is disappointing. Which maybe explains why rendering and smooth scrolling performance is where it is. When quickly auto-scrolling a page like “https://www.flickr.com/explore” Firefox destroys Chrome which is the definition of jank, stutter and hang.
“Smooth scrolling” easily goes to FF. Most weekdays I see 400-500 feeds that I will look through using Feedly and I like to read the title for each article while continuously scrolling which is impossible with Chrome unless I use auto-scroll instead of the mousewheel and then auto-scroll interferes with me opening articles in background tabs. I’ll open a dozen or two before going through them. For years I’ve been able to scroll And read at the same time in FF and the scrolling experience in Chrome doesn’t allow me to do that.
“Font rendering” easily goes to FF. Long time users of Chromium browsers probably aren’t even aware of the differences. I actually use an extension to improve font rendering in chromium browsers, it’s disabled in the screenshots. An extension for font rendering!?!
“its still behind chrome in latency with websites that carry many objects”
What exactly are you measuring? Have any examples? Page load time without cached elements is fairly equal. I have a screenshot of Chrome and Firefox loading 2200+images and the difference is less than a second, 21.3s vs 20.5s. I personally would call that insignificant. When the page is cached Chrome is often faster but I will almost always need to use the dev tools to see the difference that is more often than not imperceptible. On my hardware cached pages in Chrome are often faster than cached pages in FF but I’m mostly seeing an advantage that is measured in milliseconds but then graphics rendering more than makes up for it once you start scrolling the page. I haven’t even talked about video playback and dropped frames.
Battery life I’ve never really given any thought to because I have access to the power grid pretty much 24 hrs a day. So… :)
FF isn’t perfect but Chrome certainly isn’t either. Even if I completely disregard the Google problem, from what I’m seeing FF does many things much better than Chrome, Vivaldi, Waterfox, Pale Moon and yes even FF 52ESR. The ONLY thing I’m missing in FF right now is a TMP equivalent session manager.
Agree with your opinion about smooth scrolling.I like the feeling of scrolling in Firefox, it’s suitable for reading an article slowly.
And yes Firefox still got things to improve . For example, when I switch from my mouse to graphics tablet, Firefox always respond slowly,or even just get crashed.BTW,I guess only Microsoft is serious about “Windows Ink”, because I found only Edge can quickly respond to graphics tablet.Chrome behaves better than Firefox,but still not perfect.
I’ve heard that Firefox recently supported Windows’s dark mode and timeline. Hope that it can better support Windows Ink , too,so that I wouldn’t have to open edge when using a graphics tablet.
spotted a few typos (please delete this comment)
“The switch from using the CPU to do the heaving (*heavy) lifting in regards to rendering to the GPU should improve performance of the entire process significantly.”
“specific images entirely coded in HTML & CSS are not corrected (*correctly) rendered”.
Hmmm, I thought this was already in place and wondered why I wasn’t seeing much speed improvement in the portable versions I’ve been trying to test to see if I can wrangle them into something half as good as pre-57.
Looks like I’ll have to stick with 56 for a bit longer. 6 versions later and they still haven’t delivered on the performance improvements they said *required* butchering the interface and addons systems.
They’ve delivered some performance improvements, which yes, did require butchering the add-on system. WebRender is another performance boost, also enabled by the work done for Firefox 57 and by throwing away the previous add-ons.
Which performance improvements specifically required butchering the add-on system? I’m happily running Stylo on Waterfox (which is based on 56) and was already using it on Nightly <= 56.
At some point over the past few years, Google finally realised that they needed to tinker with their browser’s battery and CPU usage, and have consequently devoted much effort and resources to solving the problem. Today, on Mac, Chrome runs circles around Firefox in terms of battery life. With all the goodwill in the world, until Mozilla do the same, it is almost impossible to rely on Firefox while using a MacBook of any kind. I wish we’d hear about similar projects at Mozilla – a wholesale revisit of why Firefox CPU usage on Mac is so damn high.
This is completely flat out false info that I think it was made up on the spot.
Firstly, Chrome does NOT provide those type of performance edits. Those are done by the Open Chromium Project (Simular names, but vastly different companies and beliefs).
Chrome has been for the past couple years and STILL is, the worst offender for battery drain AND CPU over usage, then you resort to saying “Chrome running circles around Firefox in regards to battery usage”.
*Chuckles* did you just make that part up in hopes that no one would call you out on it?!? The majority of current performance stats show that, without a doubt that Firefox uses a good couple chunks less of ram and pulls even more ahead of Chrome in the ram usage department when Firefox is using ~30+ tabs. Firefox also uses about 1/4 of the CPU resorces that are required by Chrome. In battery life, they both suck pretty bad, but Firefox still pulls ahead of Chrome in power consumption (although you wont be getting an extra hour out of Firefox or anything….
Important note, if you are on the go with a MacBook, care about your batt life and are not using Safari exclusively then your a plain idiot…
As an example, the worse applications you can run on your laptop in regards to hogging ram and draining your battery are the apps built with the Electron Framework. Guess what the Electron Framwork is? yep it’s just the same renderer that comes with Chrome, install some of those apps, open Activity Monitor and watch your battery waste away….
Wew lad, running NIGHTLY with WEBRENDER enabled on my GTX 1080Ti on Windows 10 FEEEEEELS SO BUTTERY SMOOOOOOTH WEW MOZILLA GREAT JOB WITH RUST AND SERVO AND WEBRENDER
[usual-XUL-sarcasm] But muuuuuh I can no longer have my XUL/XPCOM display pinky ham on the top of the browser that’s making the whole browser janky!!! [/usual-XUL-sarcasm]
I’ve been running with gfx.webrender.all;true for a while now. Do I need to toggle the qualified as well?
Pretty sure, you don’t.
Looks nice this new part of Quantum transition, but me, who i’m using both, Mozilla Firefox Stable and Mozilla Firefox Developer Edition on GNU/Linux, without a GPU dedicated, i’m using only the iGP, i really hope this WebRender will be available for me too, not only for the users who have GPU.
It does work for me, on Linux on Firefox Nightly with an Intel HD Graphics 4000. (I’ve forced it on by setting “gfx.webrender.all”.)
Obviously, though, with such a weak GPU, the speed-up is not as significant as with a stronger GPU. Still noticeable, though, as it at the very least frees up the CPU to do other things.
It will get better when they optimize stuff for Intel iGPs (it’s even their goal since most of their userbase is bound to Intel iGPs)
Martin, please, help just a bit. I use FX63 beta 8 and I created these 2 parameterers in about:config
Does it mean it works? I mean the new systeam? I created via New Booleans and True.
Check WebRender under about:support, it also depends on the hardware.
I have an Nvidia GTX1060 6GB. When it says webrender, though? Ah! Saw it! It’s working. Compsositing:Webrender. Nice, thanks.
By the way, so far Webrender on 63 beta 9 is working great.
Good essay. I think other web browsers will also make use of GPU for rendering or other stuff in near future.