4 ms·

You've just started me down a rabbit hole of reading, I'm so confused now that there is even the idea of a 'hardware cursor' of an idea so clearly implemented i

You've just started me down a rabbit hole of reading, I'm so confused now that there is even the idea of a 'hardware cursor' of an idea so clearly implemented in software.

kiririn 3y ago
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.
anyfoo 3y ago
It popped up first some time in the 90s (or at least that's when I first became aware of it), long before any "3D accelerators" or similar became available. Telling a graphics card "here's a bitmap, please render it at these coordinates, over the framebuffer content" is so much easier and more efficient than, in the earlier days, rendering a cursor into the framebuffer (and then undoing that for the next frame), at the rate where this needs to happen (pretty much every frame) to boot. I don't know if in modern times, this could be reasonably achieved through compositing, but I suspect "here's the bitmap, render it here" is still easier, conceptually at least. > of an idea so clearly implemented in software. As an aside, many hardware things are ideas that could be clearly implemented in software.
- tredre3 3y ago
  > I don't know if in modern times, this could be reasonably achieved through compositing Evidently it can, as Wayland does it, but the result is pretty mediocre.
  - anyfoo 3y ago
    Yeah, it's the "reasonably" part that I wasn't sure of. At the end of the day, just updating the coordinates in some hardware registers to effectively move the cursor still sounds much simpler (and with more potential for efficiency, as the graphics card can decide how to do it) to me, yeah.
  - asddgsgsaxg 3y ago
    [dead]
  - kaba0 3y ago
    As mentioned, basically every wayland compositor does an additional hardware plane for the cursor, so it does it properly and the results are good.
kaba0 3y ago
Well, your cursor would otherwise constantly damage every buffer underneath it, demanding constant redraws just from moving the mouse across. If you have 2 hardware planes and simply composite one over the other at the hardware level, this won’t happen. If you ever had the “fortune” to get a kernel that is brokenly busy, you might have seen a completely irresponsive static image, but the cursor might still move. This is also due to this.

You've just started me down a rabbit hole of reading, I'm so confused now that there is even the idea of a 'hardware cursor' of an idea so clearly implemented in software.

kiririn 3y ago

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.

anyfoo 3y ago

It popped up first some time in the 90s (or at least that's when I first became aware of it), long before any "3D accelerators" or similar became available. Telling a graphics card "here's a bitmap, please render it at these coordinates, over the framebuffer content" is so much easier and more efficient than, in the earlier days, rendering a cursor into the framebuffer (and then undoing that for the next frame), at the rate where this needs to happen (pretty much every frame) to boot. I don't know if in modern times, this could be reasonably achieved through compositing, but I suspect "here's the bitmap, render it here" is still easier, conceptually at least. > of an idea so clearly implemented in software. As an aside, many hardware things are ideas that could be clearly implemented in software.

tredre3 3y ago
> I don't know if in modern times, this could be reasonably achieved through compositing Evidently it can, as Wayland does it, but the result is pretty mediocre.
- anyfoo 3y ago
  Yeah, it's the "reasonably" part that I wasn't sure of. At the end of the day, just updating the coordinates in some hardware registers to effectively move the cursor still sounds much simpler (and with more potential for efficiency, as the graphics card can decide how to do it) to me, yeah.
- asddgsgsaxg 3y ago
  [dead]
- kaba0 3y ago
  As mentioned, basically every wayland compositor does an additional hardware plane for the cursor, so it does it properly and the results are good.

kaba0 3y ago

Well, your cursor would otherwise constantly damage every buffer underneath it, demanding constant redraws just from moving the mouse across. If you have 2 hardware planes and simply composite one over the other at the hardware level, this won’t happen. If you ever had the “fortune” to get a kernel that is brokenly busy, you might have seen a completely irresponsive static image, but the cursor might still move. This is also due to this.