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.
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.
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
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.
* 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`.
> 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.
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.