Firefox 58: Off-Main-Thread painting promises performance improvements
Mozilla plans to introduce Off-Main-Thread painting in the next stable version of the Firefox browser to improve the browser's performance significantly.
Basically, what Mozilla did was move rasterization to its own thread. When Firefox renders a web page, certain activities happen in the background.
Three of the four, making a display list, assigning layers and rasterization, happen in the main thread, while compositing happens in a separate thread.
Mozilla's solution to improve performance records commands for rasterization in the main thread, but sends these recorded commands to the new paint thread where the rasterization happens. From there, data is sent to the compositor thread.
The cost of rasterization depends on a number of factors including the display resolution. Rasterization is more expensive the higher the monitor resolution is, about ten times on a 4K screen when compared to a 1024x768 screen according to Mozilla.
The effect that Off-Main-Thread painting has on Firefox's performance is significant. Mozilla measures performance by analyzing how much time rasterization requires.
In Firefox 57, rasterization that used less than 10% of the paint cycle occurred 51% of the time. Off-Main-Thread painting improved that figure to 80% in Firefox 58.
Rasterization costs used 50% or more of a paint cycle 21% of the time in Firefox 57. With Off-Main-Thread painting enabled in Firefox 58, that figure dropped to just 4%.
Mozilla created a benchmark to measure performance in frames per second. The benchmark simulates a heavy workload scenario by "spending 14ms of each frame spinning the CPU on JavaScript, and then forcing the browser to re-render a complex SVG pattern".
The FPS improved in the benchmark by 30% with Direct2D and by 25% with Skia in Firefox 58 when compared to Firefox 57.
Mozilla plans to improve Off-Main-Thread painting further. The organization's engineers have set their sight on parallel painting for instance, and on resolving some of the outstanding issues, for instance that Firefox does not support "rasterizing 'mask' layers on the paint thread" currently.
You find additional -- technical -- information on Off-Main-Thread painting on the Mozilla GFX blog.
Will users notice the improvement? It depends on their system, and what they do on the Internet.
I know Mozilla/Firefox gets a lot of hate by some here and in other segments of the internet, but as a former die-hard Chrome user I have to say I love what I have seen from Firefox 57 and look forward to the already blazing speed getting even better in future updates.
That’s fair. I can see the appeal of 57 to Chrome users (I believe that appealing to Chrome users was the entire point of the makeover). Personally, I have always strongly disliked Chrome. Perhaps that dislike might be why 57, on the whole, doesn’t get me terribly excited.
I use Startpage as my search engine and just noticed this message from them:
“Firefox’s latest update (57.0.1) aggressively tries to reset your default search engine to Google! To make StartPage your default search engine again after the update, please follow the instructions in this support article:
https://support.startpage.com/index.php?/Knowledgebase/Article/View/199/0/how-do-i-add-startpage-to-firefox-as-a-default-search-engine
You may want to bookmark this article now.”
It could have a connection to these news:
https://www.bloomberg.com/news/articles/2017-11-14/google-pays-to-put-search-engine-back-on-firefox-browser-in-u-s
Just updated to 57.0.2 and fortunately this time it did not switch my default search engine from Startpage to Google.
I actually really really like the speed of Quantum. And paired with Bookmark OS for bookmarking my browsing has never been better
come on Mozilla(!) the only thing keeping me tied to Chrome is ‘d3js’ rendering in SVG, if Firefox does a better job than at rendering it then I can finally get rid of Chrome!
SVG rendering will get improved greatly with Pathfinder, a GPU-based font rasterizer. It speeds up any vector graphics so SVG and PDF too.
It is going to be swapped into WebRender or along with WebRender, not sure exactly, some time later. The most drastic speed increase should be for computers 2012 and up, but others will benefit too. I don’t see it released until the second part of 2018 though.
Glad to report that after 2 updates FF 57 finally works like a normal browser on Linux.
But I have a slightly off-topic Firefox problem/question – for a while before, and still now on 57, YouTube is still totally slow. Takes a while to load the page, and around 15 seconds to start playing a video. It happens even if I start with add-ons disabled, or in private mode (logged out). I did a search on various websites and I see that many people have the same problem with FF, but nothing helps and no one can figure out why. On the other side, YouTube works normally on Pale Moon, Chrome, Opera, any other browser (page loads fast, videos start in a few seconds). The only difference I can see (with same add-ons) is that uMatrix shows that Firefox has loaded 149 YouTube cookies (in the top left field) but, for example, Chrome loads only 11. Does anyone have any ideas?
> uMatrix shows that Firefox has loaded 149 YouTube cookies
That doesn’t sound right. I am wondering if your Firefox profile needs some fixing, maybe its cookie storage has become huge for some reasons. Look at “Show Cookies…” in Preferences, see if it seems you have a lot of them from many sites. If so, try removing them all (this will log you out of active sessions) and restart the browser. See if this helps with performance.
I delete all cookies except for the pages where I’m logged in, about once a week, but yes, I never deleted the Google sign-in ones (as I’m using 2-factor auth and I’m lazy)…
OK, I did it now and after I logged in there’s just 13 cookies. I guess there was something wrong (could be VPN, could be the “YouTube download” add-ons I was testing, who knows). The page loads almost normally fast, comments load fast too, although the videos still start slower than in other browsers. But it’s an improvement. Thanks! :-)
Firefox 57 wasn’t faster than Chrome on any of my devices, so I’ll stick with Chrome.
Chrome does not have any of the customization options of Firefox 57, so I’ll stick with Firefox.
@John
Yes you can. Here are example screenshots undoing many UI changes since Firefox 29: https://github.com/Aris-t2/CustomCSSforFx/issues/1
Firefox 57 severely restricts customizations compared to prior releases, so I can’t undo many of the UI changes that get in my way. I’ll stick with Waterfox.
Firefox doesn’t have many compared to pre-57 either. Plus not everyone cares about customising, they just want a fast, no-frills browser. Not that I’d probably pick chrome and haven’t.
I’ve been using FF58 dev version and it’s way more responsive than pre-servo firefoxes. However, there’s still something about the way FF renders pages that seem *laggy* to me. It’s like v-sync is off or something. On Chrome, Amazon pages get drawn nearly instantly whereas FF58 still lagg behind just so slightly with the rendering. Especially when you start scrolling while it’s rendering all the dom. I don’t know how to describe it precisely but that’s what it feels like to me. I hope WebRender get done soon, maybe it’ll improve it.
That graph is extremely deceptive.
They are not made for your grandma is all. The engineer who blogged about this said:
“The two graphs below are unfortunately a bit difficult to read or condense, but they are straight from our public Telemetry dashboard. On the left is data from Firefox 57, and on the right is data from Firefox 58. The horizontal axis is how expensive rasterization was as a percentage of the total frame time. The vertical axis is how often that particular weighting occurred.”
You can see pretty clearly that rasterizations that take more than 10% of frame budget become consistently rarer.
This change is nice but it’s nothing like WebRender.
– How relevant is this once WebRender takes over and combines paint and composite?
– WebRender will bypass this entirely, but it will take a *long* time before WebRender ships to all configurations (due to platform/hardware/driver differences, it will progressively be rolled out starting with well tested configurations). In the mean time it’s great to have optimizations such as this.
Deceptive how? It clearly shows less time being spent on the task at hand between versions.