Hacker News Reader

Comment by actionscripted | Hacker News Reader

Enabled in FF Nightly 65.0a1 (2018-10-26) (64-bit) and it felt a little sluggish especially with regards to scrolling. I understand it's in beta but I guess I was expecting things to "feel" faster. Tried resizing larger sites/pages and things felt snappy but scrolling felt jumpy and off.

That said, can't wait for this to come out of beta!

View on HN

If you're on windows, it could be a compositor bug. Does it only feel sluggish with mousewheel scrolling or does dragging the scrollbar feel bad too?

Could be this bug, for example: https://bugzilla.mozilla.org/show_bug.cgi?id=1490991 Maybe worth chiming in if it is.

I've never used smooth scrolling in any browser (Firefox, Chrome, IE) that didn't feel laggy. It's the first thing I turn off anymore.

Safari and Edge with touch scrolling are buttery smooth! If you’re talking about a smooth scrolling option imposed on a clicky mouse wheel, I’m not sure if it’s even possible it is to make that feel snappy.

Yep, Edge gets it right when you have a precision trackpad. Chrome and Firefox unfortunately do not track the motion on the trackpad nearly as well

I've experienced the exact same thing on latest thunderbird betas and nightlies.

Its a shame that GPU support by Mozilla products is in such abysmal state. Meanwhile Google has working hardware accelerated video decoding AND decent GPU support in Chrome.

Firefox has had hardware video decoding and GPU support for like 15 years? This is just a new graphics stack.

It doesn't on Linux (see https://bugzilla.mozilla.org/show_bug.cgi?id=1210726 and https://bugzilla.mozilla.org/show_bug.cgi?id=594876).

As the sibling comment mentions, not on Linux. Perhaps I should've been clearer, but the point still stands.

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.)

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/

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.

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.

> 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

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.

Chromium has long-standing unresolved issues about adding GPU acceleration for video decoding too?

https://bugs.chromium.org/p/chromium/issues/detail?id=463440

https://chromium-review.googlesource.com/c/chromium/src/+/53...

Honestly, I think it isn't worth it, as long as we're on X. X11 is not a reasonable protocol, and Xorg is not a reasonable implementation anymore. It's had a good run, but it's time to move on.

Will the situation improve with Wayland? It seems like Firefox is generally moving in the direction of natively supporting Wayland but it doesn't seem like a high priority for now.

I have some working preliminary Wayland integration for WebRender as of this week. However, there's a whole lot more than WebRender integration that needs to get done for Firefox to stand up on Wayland.

Thanks for the info. Obviously WebRender and Wayland integration are separate concerns but I was mostly curious if you had any idea if Wayland would address the issues you were running into with X11/Xorg.

Yes, Wayland is looking a lot better. The most important feature is transaction support, which is weird in Wayland but better than X, which has none at all.

Reply on news.ycombinator.com