5 ms·

It's not unique. Wayland has a tearing protocol. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/staging/tearing-control?ref_type=heads ht

It's not unique. Wayland has a tearing protocol. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/staging/tearing-control?ref_type=heads https://gitlab.freedesktop.org/wayland/wayland-protocols/-/t...

mrob 3y ago
This is something that every application has to opt in to individually. It's not a global setting like TearFree.
- RVuRnvbM2e 3y ago
  This is just untrue.
  - mrob 3y ago
    From the XML file that describes the protocol: "This global is a factory interface, allowing clients to inform which type of presentation the content of their surfaces is suitable for." Note that "global" refers to the interface, not the setting. Which Wayland compositor has the equivalent feature of "xrandr --output [name] --set TearFree off"?
- kaba0 3y ago
  Which is the correct default? No application should unknowingly render half-ready frames, that’s stupid. The few niches where it makes sense (games, 3D applications) can opt into it, and do their own thing.
  - badsectoracula 3y ago
    That is subjective, i do not want the input latency induced by synchronizing to the monitor's refresh rate in my desktop as it makes it feel sluggish. The only time i want this is when i watch some video (and that is of course only when i actively watch the video, sometimes i put a video at the background when i do other stuff) - so for my case the correct default is to have this disabled with the only exception being when watching videos.
    - kaba0 3y ago
      Okay, and then the program will get an event, that propagates down to the correct component, which reacts some way, everything that changes due to that are damaged, and every damaged component is re-rendered with synchronization from the framework itself. It has to be specifically coded (e.g. text editor directly writing to the same buffer the rendered character) to actually make efficient use of tearing, it will literally just tear otherwise with zero benefits.
      - mrob 3y ago
        You don't need to do anything special. Just render to the front buffer immediately and don't worry about the current scanout position. If it's above the part of the screen you're updating, great, you saved some latency. If it's below, latency is the same as if you waited for vsync. And if it's in the middle, you at least get a partial update early.
        play_ac 3y ago
        The average human reaction time is 250ms. The amount of latency you'd save from that on average is unnoticeable, and in exchange you get the appearance of stuttering and corruption from the tearing.
        sph 3y ago
        The meme was "the eye can't see more than 25fps anyway", which is less than 50ms. It's a meme because it's of course incorrect. There is a huge difference between how long it takes us to acquire and react to what our retina is sensing (in the order of hundreds of ms), and keeping track of a moving/evolving shape (<5ms). Here you are saying that latency of 250ms is unnoticeable, which is utter nonsense.
        play_ac 3y ago
        Your comment has nothing to do with the conversation. The reason to have low latency when typing text is so you can correct mistakes. That requires the full response time. There's no moving or evolving shapes. Maybe proofread your own comments before throwing around accusations of "utter nonsense".

mrob 3y ago

This is something that every application has to opt in to individually. It's not a global setting like TearFree.

RVuRnvbM2e 3y ago
This is just untrue.
- mrob 3y ago
  From the XML file that describes the protocol: "This global is a factory interface, allowing clients to inform which type of presentation the content of their surfaces is suitable for." Note that "global" refers to the interface, not the setting. Which Wayland compositor has the equivalent feature of "xrandr --output [name] --set TearFree off"?
kaba0 3y ago
Which is the correct default? No application should unknowingly render half-ready frames, that’s stupid. The few niches where it makes sense (games, 3D applications) can opt into it, and do their own thing.
- badsectoracula 3y ago
  That is subjective, i do not want the input latency induced by synchronizing to the monitor's refresh rate in my desktop as it makes it feel sluggish. The only time i want this is when i watch some video (and that is of course only when i actively watch the video, sometimes i put a video at the background when i do other stuff) - so for my case the correct default is to have this disabled with the only exception being when watching videos.
  - kaba0 3y ago
    Okay, and then the program will get an event, that propagates down to the correct component, which reacts some way, everything that changes due to that are damaged, and every damaged component is re-rendered with synchronization from the framework itself. It has to be specifically coded (e.g. text editor directly writing to the same buffer the rendered character) to actually make efficient use of tearing, it will literally just tear otherwise with zero benefits.
    - mrob 3y ago
      You don't need to do anything special. Just render to the front buffer immediately and don't worry about the current scanout position. If it's above the part of the screen you're updating, great, you saved some latency. If it's below, latency is the same as if you waited for vsync. And if it's in the middle, you at least get a partial update early.
      - play_ac 3y ago
        The average human reaction time is 250ms. The amount of latency you'd save from that on average is unnoticeable, and in exchange you get the appearance of stuttering and corruption from the tearing.
        sph 3y ago
        The meme was "the eye can't see more than 25fps anyway", which is less than 50ms. It's a meme because it's of course incorrect. There is a huge difference between how long it takes us to acquire and react to what our retina is sensing (in the order of hundreds of ms), and keeping track of a moving/evolving shape (<5ms). Here you are saying that latency of 250ms is unnoticeable, which is utter nonsense.
        play_ac 3y ago
        Your comment has nothing to do with the conversation. The reason to have low latency when typing text is so you can correct mistakes. That requires the full response time. There's no moving or evolving shapes. Maybe proofread your own comments before throwing around accusations of "utter nonsense".