- "Smoother pointer movement: performance improvements mean that the pointer will move smoothly even when the computer is busy."
That's a very short description of what sounds like maybe a very interesting optimization? There've been giant HN threads arguing about why mouse pointers are not smooth.
> it uses a CRTC vblank deadline based approach to postpone posting KMS updates until as late as possible, and uses this method to achieve lower latency cursor movements, as well avoiding potential cursor stutter when the main thread is too busy to manage completing a frame in time.
Mouse movements no longer happen on main thread.
And the RT KMS thread delays posting the update until just before a deadline, to make sure the mouse is samples at the last possible moment! What a neat & straightforward & simple hack, sampling late. I'm sure this kind of stuff is what Good game devs have been doing for decades but still amazes me to read this.
Yep in gamedev it's called frame pacing. If you have a 16 ms frame budget and you know rendering will take about 4 ms, you can sleep for 10 ms, sample the latest possible inputs, and kick off rendering just in time to make the deadline.
If you estimate wrong, you start missing frames. If you don't do any frame pacing, the game always has a little bit of preventable input lag.
I only learned about this a couple years ago, but I think I felt it years ago - One of my games just seemed to feel better with a 10 millisecond sleep right after I submitted each OpenGL frame. In a world where you can't control hardware and OS lag, that 10 ms of free lag reduction is wondrous.
TBF, for the longest time XFree86/XOrg handled pointer events/updates in a signal handler. The only time you'd have pointer stutters in that epoch of X on Linux was because interrupts were disabled for too long (`hdparm -u` ring a bell for anyone?).
At some point this was moved to an input thread, probably around when glamour happened. You can't do complex junk like OpenGL calls from within a signal handler.
Some things were easier to do better when X implemented the full graphics stack.
Nowadays in a Wayland world the compositor is still hamstrung by what execution contexts it can call its underlying GPU-acceleration API from. So I doubt we'll see the same kind of lean and mean signal handler approach of ye olde X. The best you can probably do there is a dedicated high-priority thread.
It's not just Linux, it's everyone really, and for many things (not just Amigas). There are many places where people have failed to learn from the past, and reinvented the wheel badly.
That's a very short description of what sounds like maybe a very interesting optimization? There've been giant HN threads arguing about why mouse pointers are not smooth.
https://news.ycombinator.com/item?id=34095032 ("24-core CPU and I can’t move my mouse", 253 comments)