8 ms·

No screen tearing is a major benefit of using a compositor.

mrob 3y ago
And screen tearing is a major benefit of not using a compositor. There's an unavoidable tradeoff between image quality and latency. Neither is objectively better than the other. Xorg has the unique advantage that you can easily switch between them by changing the TearFree setting with xrandr.
- RVuRnvbM2e 3y ago
  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.
- JelteF 3y ago
  Could you explain in what scenario you think it is better to have a display show two half images slightly faster (milliseconds) than one full one?
  - mrob 3y ago
    Text editing. I mostly work on a single line at a time. The chance of the tear ending up in that line is low. And even if it does, it lasts only for a single screen refresh cycle, so it's not a big deal. And you're not limited to two images. As the frame rate increases, the number of images increases and the tear becomes less noticeable. Blur Busters explains: https://blurbusters.com/faq/benefits-of-frame-rate-above-refresh-rate/ https://blurbusters.com/faq/benefits-of-frame-rate-above-ref...
    - kaba0 3y ago
      As the frame rate increases, the latency decreases, making it a non-issue. I rather chose this option, over blinking screens.
      - mrob 3y ago
        The minimum latency is bottlenecked by the monitor unless you allow tearing.
        kaba0 3y ago
        No, the monitor’s refresh rate is a hard limit on the minimal maximal-latency. It doesn’t mean that you are actually close to that minimum, or that it is the hard limit that is active, aka the bottleneck.
    - Too 3y ago
      Text editing is mostly about reading, not writing. Scrolling up and down code is actually one of the worst scenarios i can think of, where you absolutely don't want to have tear. Because even as the document is moving you are still reading it. When touch typing, fingers work decoupled from the eyes anyway, unless you are waiting for the intellisense or copilot prompt, that is usually constrained by language servers anyway, not the framerate.

mrob 3y ago

And screen tearing is a major benefit of not using a compositor. There's an unavoidable tradeoff between image quality and latency. Neither is objectively better than the other. Xorg has the unique advantage that you can easily switch between them by changing the TearFree setting with xrandr.

RVuRnvbM2e 3y ago
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.
JelteF 3y ago
Could you explain in what scenario you think it is better to have a display show two half images slightly faster (milliseconds) than one full one?
- mrob 3y ago
  Text editing. I mostly work on a single line at a time. The chance of the tear ending up in that line is low. And even if it does, it lasts only for a single screen refresh cycle, so it's not a big deal. And you're not limited to two images. As the frame rate increases, the number of images increases and the tear becomes less noticeable. Blur Busters explains: https://blurbusters.com/faq/benefits-of-frame-rate-above-refresh-rate/ https://blurbusters.com/faq/benefits-of-frame-rate-above-ref...
  - kaba0 3y ago
    As the frame rate increases, the latency decreases, making it a non-issue. I rather chose this option, over blinking screens.
    - mrob 3y ago
      The minimum latency is bottlenecked by the monitor unless you allow tearing.
      - kaba0 3y ago
        No, the monitor’s refresh rate is a hard limit on the minimal maximal-latency. It doesn’t mean that you are actually close to that minimum, or that it is the hard limit that is active, aka the bottleneck.
  - Too 3y ago
    Text editing is mostly about reading, not writing. Scrolling up and down code is actually one of the worst scenarios i can think of, where you absolutely don't want to have tear. Because even as the document is moving you are still reading it. When touch typing, fingers work decoupled from the eyes anyway, unless you are waiting for the intellisense or copilot prompt, that is usually constrained by language servers anyway, not the framerate.