4 ms·

The cursor has to be rendered outside the normal graphics pipeline to feel responsive. To match it you would need to render the desktop at 2x or so the mouse po

The cursor has to be rendered outside the normal graphics pipeline to feel responsive. To match it you would need to render the desktop at 2x or so the mouse polling rate (like 2000 fps or so for a good mouse)

whizzter 3y ago
1: Mouse polling rate needs to be higher than rendering rate and and NOT the other way around. The higher the better because it guarantees that there is less of a delay between the latest sample from the mouse and the time the mouse cursor is rendered. (There are plenty of articles about how to minimize latency for fighting games by going from triple to double buffering and sampling just at the start of the "double" rendering phase) 2: Hardware cursors of old were akin to sprite hardware on consoles, here the hardware did compositing (or pre-compositing) operations on a per-line basis just before sending the frame contents to the display. On platforms like the C64 you only had 8 sprites in hardware but if you tuned your code to race the display processor you could have more by updating the sprite positions to lines below (so still limited to 8 per line but non-overlapped it was possible to have more). 3: Looking at WDDM there seems to be 2 ways cursors could be handled, either Windows uses overlays under the hood for the cursor (if overlays support operations like alpha-blending automatically) or the compositor pre-empts the GPU when it's time for an display update, modern GPU's are fast enough that compositing operations should be able to finish quickly enough to meet frame-times but if done off-screen for safety it could be producing an extra frame of latency. Regardless the GPUs should be fast enough today to make it happen whenever needed even if not using the classic ways.
- kiririn 3y ago
  Right but say the mouse is a constant 1000hz. To get the most recent sample on the screen as quickly as possible you either need the entire rendering pipeline to run ridiculously fast (the 2000 fps example), render just in time before vsync with impossible accuracy, or bypass as many clocks and buffers as possible and blit the cursor with hardware magic. There’s a reason it’s still done this way after so many years of advancement
  - worthless-trash 3y ago
    Reading this thread has been a great experience, I love HN.
piaste 3y ago
Why? There is still a much lower cap because of the refresh rate. Rendering at 2k fps would be useless.
- kiririn 3y ago
  The frame could be generated several ms after the mouse movement occurred You can sort of solve it by ensuring the frame is generated (or at least the cursor added to it) just in time for vsync (ie as late as possible) but it won’t be as good as a traditional hardware cursor
kaba0 3y ago
I don’t think it’s true. I have written a toy compositor where I didn’t bother with a separate hardware plane for the cursor and it was snappy as hell at 60fps.

whizzter 3y ago

1: Mouse polling rate needs to be higher than rendering rate and and NOT the other way around. The higher the better because it guarantees that there is less of a delay between the latest sample from the mouse and the time the mouse cursor is rendered. (There are plenty of articles about how to minimize latency for fighting games by going from triple to double buffering and sampling just at the start of the "double" rendering phase) 2: Hardware cursors of old were akin to sprite hardware on consoles, here the hardware did compositing (or pre-compositing) operations on a per-line basis just before sending the frame contents to the display. On platforms like the C64 you only had 8 sprites in hardware but if you tuned your code to race the display processor you could have more by updating the sprite positions to lines below (so still limited to 8 per line but non-overlapped it was possible to have more). 3: Looking at WDDM there seems to be 2 ways cursors could be handled, either Windows uses overlays under the hood for the cursor (if overlays support operations like alpha-blending automatically) or the compositor pre-empts the GPU when it's time for an display update, modern GPU's are fast enough that compositing operations should be able to finish quickly enough to meet frame-times but if done off-screen for safety it could be producing an extra frame of latency. Regardless the GPUs should be fast enough today to make it happen whenever needed even if not using the classic ways.

kiririn 3y ago
Right but say the mouse is a constant 1000hz. To get the most recent sample on the screen as quickly as possible you either need the entire rendering pipeline to run ridiculously fast (the 2000 fps example), render just in time before vsync with impossible accuracy, or bypass as many clocks and buffers as possible and blit the cursor with hardware magic. There’s a reason it’s still done this way after so many years of advancement
- worthless-trash 3y ago
  Reading this thread has been a great experience, I love HN.

piaste 3y ago

Why? There is still a much lower cap because of the refresh rate. Rendering at 2k fps would be useless.

kiririn 3y ago
The frame could be generated several ms after the mouse movement occurred You can sort of solve it by ensuring the frame is generated (or at least the cursor added to it) just in time for vsync (ie as late as possible) but it won’t be as good as a traditional hardware cursor

kaba0 3y ago

I don’t think it’s true. I have written a toy compositor where I didn’t bother with a separate hardware plane for the cursor and it was snappy as hell at 60fps.