3 ms·

This boils down to software cursor vs hardware cursor.

mort96 2y ago
I'm pretty sure this is incorrect? I half-remember having cursor rendering bugs on GNOME Wayland with NVidia ages ago which I had to disable something h hardware cursor related to fix. But I don't know if that's what you're talking about or not. Could you link to a source which says that Mutter doesn't make use of hardware cursor? (Hi, author here by the way! ... Don't worry, that disabling hardware cursors thing was at least one OS re-install ago)
- mariusor 2y ago
  I wonder if the latency is due to the compositor receiving a damage event for the area of the cursor, thus being a frame late to render. But probably that wouldn't be an issue with hardware cursors.
- BearOso 2y ago
  Yes, it should use hardware cursor by default on most hardware. But I don't think that RPi's VideoCore (in the linked article) supports hardware cursor or multiple planes. The difference between X11 and Wayland might then be that the cursor isn't vsynced as part of the composite process on X11, where it is on Wayland. Mutter definitely throttles cursor updates on Wayland, too, which will contribute slightly to latency even with a hardware cursor. In general, with Wayland, the compositor is responsible for cursor updates, and I'm not sure which other ones throttle. But that would be where the difference comes from when using hardware cursors.
  - dividuum 2y ago
    Pis VideoCore has like 48 planes split up between writeback and HDMI output CRTCs. There’s one explicit Cursor plane per CRTC.
    - BearOso 2y ago
      Thanks, I didn't know this. I think the difference mort96 is seeing is the cursor update throttling. If it updates at the same rate of the refresh rate then it's a crapshoot where in that interval it hits relative to vsync, with a worst case additional latency of the frame rate. X11 updates the cursor whenever it moves, so on scanout it's always where you expect it to be, even if the motion was almost immediately before vsync. I should mention that in the past there's been problematic interactions on amdgpu with atomic updates of the cursor and display planes. This resulted in either one being starved from changing, causing stuttering in one or the other depending how it was handled. IIRC, that's why the throttle is there. You could try MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0 to see if they only added the throttle to the atomic code path.
- temptemptemp111 2y ago
  [dead]
itvision 2y ago
This assumption is incorrect.
- BearOso 2y ago
  Thanks, I think you're right.
deleted 2y ago
[deleted]
hacker_homie 2y ago
I think you mean, The display server cursor (we can draw directly to the frame buffer) vs The Compositor Cursor (this involves and extra copy) It's all software.

I'm pretty sure this is incorrect? I half-remember having cursor rendering bugs on GNOME Wayland with NVidia ages ago which I had to disable something h hardware cursor related to fix. But I don't know if that's what you're talking about or not. Could you link to a source which says that Mutter doesn't make use of hardware cursor? (Hi, author here by the way! ... Don't worry, that disabling hardware cursors thing was at least one OS re-install ago)

mariusor 2y ago
I wonder if the latency is due to the compositor receiving a damage event for the area of the cursor, thus being a frame late to render. But probably that wouldn't be an issue with hardware cursors.
BearOso 2y ago
Yes, it should use hardware cursor by default on most hardware. But I don't think that RPi's VideoCore (in the linked article) supports hardware cursor or multiple planes. The difference between X11 and Wayland might then be that the cursor isn't vsynced as part of the composite process on X11, where it is on Wayland. Mutter definitely throttles cursor updates on Wayland, too, which will contribute slightly to latency even with a hardware cursor. In general, with Wayland, the compositor is responsible for cursor updates, and I'm not sure which other ones throttle. But that would be where the difference comes from when using hardware cursors.
- dividuum 2y ago
  Pis VideoCore has like 48 planes split up between writeback and HDMI output CRTCs. There’s one explicit Cursor plane per CRTC.
  - BearOso 2y ago
    Thanks, I didn't know this. I think the difference mort96 is seeing is the cursor update throttling. If it updates at the same rate of the refresh rate then it's a crapshoot where in that interval it hits relative to vsync, with a worst case additional latency of the frame rate. X11 updates the cursor whenever it moves, so on scanout it's always where you expect it to be, even if the motion was almost immediately before vsync. I should mention that in the past there's been problematic interactions on amdgpu with atomic updates of the cursor and display planes. This resulted in either one being starved from changing, causing stuttering in one or the other depending how it was handled. IIRC, that's why the throttle is there. You could try MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0 to see if they only added the throttle to the atomic code path.
temptemptemp111 2y ago
[dead]

itvision 2y ago

This assumption is incorrect.

BearOso 2y ago
Thanks, I think you're right.

deleted 2y ago

[deleted]

hacker_homie 2y ago

I think you mean, The display server cursor (we can draw directly to the frame buffer) vs The Compositor Cursor (this involves and extra copy) It's all software.