3 ms·

Asahi Lina's comment on the topic: https://lobste.rs/s/oxtwre/hard_numbers_wayland_vs_x11_input_latency#c_edq7tn https://lobste.rs/s/oxtwre/hard_numbers_wayland

by gf000 2y ago

Asahi Lina's comment on the topic: https://lobste.rs/s/oxtwre/hard_numbers_wayland_vs_x11_input_latency#c_edq7tn https://lobste.rs/s/oxtwre/hard_numbers_wayland_vs_x11_input...

hulitu 2y ago
Tl;dr: X bad and tears but Wayland with 1.5 frame latency (or more) good. Now, if you have a monitor (or TV) with 30i refresh rate, you're screwed.
- Vilian 2y ago
  1.5 is the worse case, and implementation specific
- Edman274 2y ago
  We don't even know if it's actually a 1.5 frame latency for real because the test didn't try to establish that. The author said it looked like it was 1.5 frames, but that could be a coincidence. It just looks like a 1.5 frame overhead. It could, in reality, be a constant time overhead rather than a function of frames and so would be fine with a lower frame rate. Tearing would affect everyone that uses a computer with X11 but your proposed example of a TV with 30i refresh rate would only affect the tiny subset of users that use a CRT television as a monitor, right?
  - estebank 2y ago
    I don't think there was ever a 30i screen. GP probably meant 60 interlaced, which needs two full scans for a change, so an effective 30 full frames per second, but enough for 60 half images. For a Wayland compositor and the entire hardware stack would treat it as 30hz only if it really wanted to avoid interlace artifacts, but I don't recall that being a configuration that existed in my lifetime.
ChuckMcM 2y ago
That is a great comment and everyone should read it. It also demonstrates a common truism that system goals dictate performance.
eqvinox 2y ago
I'm not sure where this absolute "tearing is bad" and "correctness" mentality comes from. To me, the "correct" thing specifically for the mouse cursor is to minimize input lag. Avoiding tearing is for content. A moving cursor is in various places along the screen anyway, which will include biological "afterglow" in one's eyes and therefore there's going to be some ghosted perception of the cursor anyway. Tearing the cursor just adds another ghost. And at the same time, this ghosting is the reason keeping cursor input lag to a minimum is so important, to keep the brain's hand-eye coordination in sync with the laggy display.
- gf000 2y ago
  What about a cursor moving over an element that requires changing its look? (E.g. you go over a link?)
  - eqvinox 2y ago
    I guess you're asking what happens if the UI element can't be updated in the same cycle? I'd say: it really doesn't matter at all, in fact it's even more argument to make the pointer as low latency as possible. The mouse pointer is your control element as the controller of the interface. The UI element (and everything else onscreen) is the computer's element. It is an interaction between two entities and there is no need to introduce an expectation that the computer be "zero frame delay" on UI elements. It certainly sucks if it's more than a few frames for it to react, but so be it. However for the mouse cursor itself, it should absolutely be immediate because it is the user's representation on this virtual surface, and as such should follow inputs without being unnecessarily impeded. (Case in point: some UIs intentionally add delay or effects [like a fade-in] to UI element response. It's a… "choice"… but sometimes it works.) Ultimately, the mouse pointer is an extension of hand-eye coordination; the only thing worse than making it lag (which you can learn to adapt to, albeit it will be very annoying) is to make it lag inconsistently (which you can't adapt to and will grow frustrated with extremely quickly.) And, unfortunately, from personal experience, the mouse pointer on Wayland gets choppy if system load is high. X11 was significantly better with this; with Wayland the compositor [kwin_wayland to be specific, might be a KDE issue] doesn't even seem to be "unnice" or have some kind of scheduling priority over other tasks — I'm not sure if I'm missing something there but that seems to be a glaring oversight on its own.

by gf000 2y ago

Asahi Lina's comment on the topic: https://lobste.rs/s/oxtwre/hard_numbers_wayland_vs_x11_input_latency#c_edq7tn https://lobste.rs/s/oxtwre/hard_numbers_wayland_vs_x11_input...

hulitu 2y ago

Tl;dr: X bad and tears but Wayland with 1.5 frame latency (or more) good. Now, if you have a monitor (or TV) with 30i refresh rate, you're screwed.

Vilian 2y ago
1.5 is the worse case, and implementation specific
Edman274 2y ago
We don't even know if it's actually a 1.5 frame latency for real because the test didn't try to establish that. The author said it looked like it was 1.5 frames, but that could be a coincidence. It just looks like a 1.5 frame overhead. It could, in reality, be a constant time overhead rather than a function of frames and so would be fine with a lower frame rate. Tearing would affect everyone that uses a computer with X11 but your proposed example of a TV with 30i refresh rate would only affect the tiny subset of users that use a CRT television as a monitor, right?
- estebank 2y ago
  I don't think there was ever a 30i screen. GP probably meant 60 interlaced, which needs two full scans for a change, so an effective 30 full frames per second, but enough for 60 half images. For a Wayland compositor and the entire hardware stack would treat it as 30hz only if it really wanted to avoid interlace artifacts, but I don't recall that being a configuration that existed in my lifetime.

ChuckMcM 2y ago

That is a great comment and everyone should read it. It also demonstrates a common truism that system goals dictate performance.

eqvinox 2y ago

I'm not sure where this absolute "tearing is bad" and "correctness" mentality comes from. To me, the "correct" thing specifically for the mouse cursor is to minimize input lag. Avoiding tearing is for content. A moving cursor is in various places along the screen anyway, which will include biological "afterglow" in one's eyes and therefore there's going to be some ghosted perception of the cursor anyway. Tearing the cursor just adds another ghost. And at the same time, this ghosting is the reason keeping cursor input lag to a minimum is so important, to keep the brain's hand-eye coordination in sync with the laggy display.

gf000 2y ago
What about a cursor moving over an element that requires changing its look? (E.g. you go over a link?)
- eqvinox 2y ago
  I guess you're asking what happens if the UI element can't be updated in the same cycle? I'd say: it really doesn't matter at all, in fact it's even more argument to make the pointer as low latency as possible. The mouse pointer is your control element as the controller of the interface. The UI element (and everything else onscreen) is the computer's element. It is an interaction between two entities and there is no need to introduce an expectation that the computer be "zero frame delay" on UI elements. It certainly sucks if it's more than a few frames for it to react, but so be it. However for the mouse cursor itself, it should absolutely be immediate because it is the user's representation on this virtual surface, and as such should follow inputs without being unnecessarily impeded. (Case in point: some UIs intentionally add delay or effects [like a fade-in] to UI element response. It's a… "choice"… but sometimes it works.) Ultimately, the mouse pointer is an extension of hand-eye coordination; the only thing worse than making it lag (which you can learn to adapt to, albeit it will be very annoying) is to make it lag inconsistently (which you can't adapt to and will grow frustrated with extremely quickly.) And, unfortunately, from personal experience, the mouse pointer on Wayland gets choppy if system load is high. X11 was significantly better with this; with Wayland the compositor [kwin_wayland to be specific, might be a KDE issue] doesn't even seem to be "unnice" or have some kind of scheduling priority over other tasks — I'm not sure if I'm missing something there but that seems to be a glaring oversight on its own.