Depending on what you perceive as snappiness, it is because of misconfiguration.
If you perceive response time of desktop enviroment snappiness, you need to configure desktop server(xorg-server, kwin_wayland, xwayland) and compositor(or disable it) to run in real-time mode. Maybe there is also “prefer smoothness” option in you desktop enviroment settings like on KDE.
If you play games, then migrate to X11. Games don’t know how to enable tearing on wayland. And in general X11 seems to work better with games.
What do you mean with real-time mode?
I only know of real-time kernels, which allow to measure/calculate the maximum response time of an application. This is important for critical processes, like braking in your car, but decreases performance slightly rather than increase responsiveness.
I mean real-time scheduler, not real-time kernel. Found an article that says kwin_wayland uses SCHED_FIFO.
man 7 sched says:
SCHED_FIFO can be used only with static priorities higher than 0, which means that when a SCHED_FIFO thread becomes runnable, it will always immediately preempt any currently running SCHED_OTHER, SCHED_BATCH, or SCHED_IDLE thread.
but decreases performance slightly rather than increase responsiveness.
Responsiveness is not performance. There are 3 main performance metrics: throughput, latency and jitter. Responsiveness is mostly latency, but sometimes jitter. You can for example run game in 30fps with 0.01s lag or in 60 fps with 1s lag. In second case FPS is higher, but, player will feel game unresponsive because of time it takes between pressing button and game showing the result.
Thanks for the link, real-time mode definitely makes sense and should be implemented for all compositors imo.
Responsiveness is not performance.
True, I miswrote. What I wanted to write was
but decreases performance slightly
rather thanin return for an increase in responsiveness.
