Comment by ttarr | Hacker News Reader

Comment by ttarr | Hacker News Reader

I've used Gnome on Wayland since first available on Fedora, that's until two days a go! What happened you might ask? Well, I had enough of slow performance, with every release I'm thinking it'll improve, it did but at slow pace.

It's beautiful, and I like the UX, but it's lacking underneath, go ahead and play a 4k clip on Wayland enabled Firefox then move the mouse pointer, it stutters like crazy.

The mouse movements/scrolling in general doesn't feel natural at all, it has some kind of weird acceleration curve, scroll on Wayland enabled Firefox for example and compare that to Firefox under X11, day and night difference, under X11 it's MacOS like smoothness.

For some weird reason, switching to X11 fixes the performance, responsiveness and mouse scrolling/acceleration/movement accuracy, without doing a thing.

Sadly, because of the above and the fact that Gnome 42 no longer does fractional scaling under X11, I had to leave Gnome behind, I'm now on Fedora 36 KDE which I'm liking so far.

* My machine (3900x/rx5500/4k monitor/mx master 3) felt very slow sometimes to the point I was going to get rid of Linux all together and go MacOS or Windows (I dislike both).

* Thanks everyone for the continued work on Desktop GNU/Linux, inc Gnome and Wayland guys.

> go ahead and play a 4k clip on Wayland enabled Firefox then move the mouse pointer, it stutters like crazy.

Either your DE or your Firefox aren't actually using Wayland because for me it's incredibly smooth, and CPU usage is in the low 10%. Fedora 35 on a 6800 XT here.

Firefox still needs tweaks to have actual complete hardware video acceleration.

I should've been more clear, Firefox is just an example, my problem is the mouse pointer being affected by heavy load of any kind on the GPU/UI thread.

As coldblues said, it's probably Mutter not having an independent thread for the mouse pointer, X11's pointer handling is independent from Mutter/KWin it seems.

See the demo here to know exactly what I'm talking about: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1241

Weird, I'm not seeing it, not even with a GPU heavy game being rendered in a window.

Interesting!

What's your monitor like? Sometimes I suspect it's because of my 4K monitor (with 1.5x scaling), that's a lot of pixels to shuffle, especially if the rendering code/pipeline is not optimised[0].

Testing my setup with a 1080p/75hz monitor[1], it's crazy fast and responsive, but mouse acceleration curve (and scroll), not speed, is still weird.

[0]See Ubuntu pushing for triple buffering for example, and other optimisation work on the past.

[1]Apparently that causes huge speedup, as it affects frame scheduling, according to one GUADEC talk by a Mutter dev.

I'm on 4K at 2x scaling.

I can easily reproduce the stuttering cursor on GNOME Wayland on all of my systems by doing this:

* move the mouse cursor evenly in a straight motion

* while moving press `Super+a` to open the application list

During the animation, i.e. when GNOME Shell is busy, the mouse cursor noticeably stutters for a moment. On my faster systems it's less apparent but still visible, except when I set the CPU governor to `performance`.

Smooth mouse input, especially when using high-DPI mice, is something that's been fixed in GNOME 42 due to release soon.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915

From that link:

> Nothing has been done here to avoid potential wayland event queue overflows, as IIUC this is being worked on separately. Although I should probably also mention that this hasn't been seen in the wild during this work.

I recently tried the new Ubuntu 22.04 LTS and the mouse stuttering was unbearable while running games via Wine. I had to switch back to Xorg to get rid of it.

> the mouse pointer being affected by heavy load of any kind on the GPU/UI thread.

It's because of stuff like this that we should treat UIs more like real time systems. There's really no good reason at all that a modern machine can't render every frame perfectly every time regardless of system load --- it's due to inadequate attention paid to isolating real-time-ish paths like mouse cursor movement, composition, input event dispatch, and so on from app-induced loads that we get weird responsiveness issues. X actually did a better job in this particular respect than your typical Wayland compositor --- it used interrupt driven mouse cursor rendering, for example.

I wonder if your Firefox is using hardware accelerated video. I know for me I had to play with some about:config knobs before Firefox actually started using hardware accelerated video. It is enabled by default on macOS and Windows, however on Linux it is not. Ensuring that Firefox was using hardware acceleration for video for me improved the performance and battery life enormously.

Firefox was just an example, anything that's heavy on the GPU yields the same problem, and yes I did have the right knobs enabled on Firefox and can confirm that HW was indeed working.

Recently however I had to disable it, see https://bugzilla.mozilla.org/show_bug.cgi?id=1759947

The issues you are experiencing with the pointer are due to the fact that on X11, the pointer is on a separate thread. This is not the case on Wayland currently, but I remember seeing some work being done about it.

Yes indeed, I believe you are referring to this WIP: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1241

There is a super nice demo there that sheds light into what I'm trying to convey.

Are you sure you were using wayland firefox? It is not always apparent. Also, follow the sibling comment on hw acceleration.

Yes, along XINPUT2 for improved scrolling.

Reply on news.ycombinator.com