[pcwalton]

This is that "GPU support", on Linux anyway.

Hardware accelerated video decoding is barely worth it on Linux. Crashes galore. Does Chromium even enable it by default?

The problem is not writing the "GPU support", but working around the mountain of Xorg bugs that it triggers. As an example just this week, I recently ripped out OS compositing support from WebRender on X because it was simply impossible to deploy without crashing. (It will still work on X, but energy usage will be worse.)

[chmln]

Glad to hear work this is something that's being worked on because Firefox is still losing market share. And that's not good news for all of us.

You may put GPU support in quotation marks, but Chromium is way snappier and faster than Firefox nightlies on my Linux box, and I suspect taking advantage of the GPU is a part of the equation.

I also suspect the whole pipeline is more optimized on Chrome. Firefox has ~3x the input latency[1] and unlike Chrome, also slaughters my CPU when watching youtube videos.

Its not like Mozilla is under-resourced. I think its just a matter of priority[2].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1408699

[2] https://blog.servo.org/2018/03/09/servo-and-mixed-reality/

[pcwalton]

I'm putting "GPU support" in quotes because "GPU support" is such a broad topic that it's impossible to pin down precisely what you might mean by it. There aren't any areas I'm aware of in which Chrome uses the GPU whereas Firefox doesn't. If anything, WebRender makes it the reverse, though since Chrome uses Skia-GL it's more of a matter of which GPU features a browser uses rather than whether a browser uses the GPU (in particular, WebRender uses the Z-buffer and the early-Z functionality, which are quite an improvement).

I will say that, in my opinion, WebRender is generally better optimized for modern graphics hardware than Skia-GL as used in Chrome, due to the reduced overdraw via aggressive use of the Z-buffer and better batching.

Often times performance bugs are just that—bugs. The existence of performance bugs doesn't necessarily indicate that "the whole pipeline" in one browser is better than the other. Browsers are broadly quite comparable in terms of the script-layout-painting pipeline these days. In the case of Firefox, I'm personally confident in the IonMonkey-Stylo-WebRender trio.

[Manishearth]

You're literally talking to one of the main initial people behind the Mozilla project that uses the GPU for browser rendering more than any other browser, on the comments of a post about this stuff making its way to a release.

Webrender has a pretty large team working on it at this point.

You have no idea what you're talking about here.

[chmln]

> You're literally talking to one of the main initial people behind the Mozilla project that uses the GPU for browser rendering more than any other browser, on the comments of a post about this stuff making its way to a release

I don't see how this vague appeal to authority adds anything to the conversation.

> Webrender has a pretty large team working on it at this point.

I guess what you're trying to say is that Firefox and Webrender in particular is a high priority for Mozilla. I would like to believe that this is true, but take a look at what Mozilla allocates its resources to[1] - Firefox Reality, Firefox Monitor, Pocket, ethics in CS, women who tech, etc. All fine and dandy, but the problem is that time is ticking for Mozilla Firefox.

Firefox is not even at feature parity with Chrome, never mind performance parity. For instance, I filed a bug[2] on bad input latency a whole year and 7 releases ago, and its still not fixed. A devtools bug for a websocket frames inspector[3] was filed 5 years ago, and its still not fixed either.

The time it takes to fix bugs and ship all these features is inversely proportional to the dedicated manpower. By the time Firefox reaches feature/performance parity with Chrome, it will have an insignificant single-digit market share, down from ~10.5% now. And that is with the incorrect assumption that Chrome will remain static.

[1] https://blog.mozilla.org/

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1408699

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=885508

[thrower123]

One must wonder, if Firefox might do better at being a browser, if they stopped chasing money by questionable integrations with tangential services and focused on their core competencies. It seems like hardly a week can go by without a new announcement that Mozilla has their fingers in some new also-ran company in a new market.