4 ms·

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

by mrob 3y ago

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".
        sph 3y ago
        Are you saying that latency in the order of 250ms when editing text is unnoticeable? Yeah, that is utter nonsense. Just try it for yourself, instead of pulling statements like that out of thin air. You would notice a difference in tens of ms even when editing text. Why do you think people cannot stand writing with VSCode for example? Re: moving/evolving shapes, I did not think I had to clarify that the brain is a massively parallel system with multiple modes of operation. Editing text does not require you to reprocess all visual signals from scratch, because that is not how the visual cortex works. The perceived latency when editing text is between pressing a key and your brain telling you "my eyes have detected a change on the screen. I will assume that it is the result of me pressing a key". It does NOT take 250ms to make this type of assumption, and is basically how our vision operates. It's a prediction engine, not a CCD sensor.
  - phkahler 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. Only if the DE or application can't keep up. Oh, it overran the frame time, so let's just dump half of it to screen... I'm still baffled that this is a problem. I tried ray tracing a hierarchy of rectangles decades ago and it was pretty fast. Should be better than real time today, and that's doing it the expensive way. I suppose the challenge is composting stuff from different processes every frame.
    - badsectoracula 3y ago
      It is not about performance/throughput. There are various factors at play: first of all, the synchronization is basically waiting for the monitor to finish displaying the last image before you send the new one. Second, unless the application takes over the screen (e.g. fullscreen games), the applications do not run in sync with the window system (and you do not want that because you do not want a single application to cause problems for other applications like hogging the screen updates). When you combine these two there is nothing really the application can do. As you wrote: > I suppose the challenge is composting stuff from different processes every frame. This is a significant part of the issue, though the fact that synchronization essentially means waiting is also another one (without synchronizing you get partial frames but those partial frames are still feedback for the user that makes the desktop feel more responsive).

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

by 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".
        sph 3y ago
        Are you saying that latency in the order of 250ms when editing text is unnoticeable? Yeah, that is utter nonsense. Just try it for yourself, instead of pulling statements like that out of thin air. You would notice a difference in tens of ms even when editing text. Why do you think people cannot stand writing with VSCode for example? Re: moving/evolving shapes, I did not think I had to clarify that the brain is a massively parallel system with multiple modes of operation. Editing text does not require you to reprocess all visual signals from scratch, because that is not how the visual cortex works. The perceived latency when editing text is between pressing a key and your brain telling you "my eyes have detected a change on the screen. I will assume that it is the result of me pressing a key". It does NOT take 250ms to make this type of assumption, and is basically how our vision operates. It's a prediction engine, not a CCD sensor.
- phkahler 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. Only if the DE or application can't keep up. Oh, it overran the frame time, so let's just dump half of it to screen... I'm still baffled that this is a problem. I tried ray tracing a hierarchy of rectangles decades ago and it was pretty fast. Should be better than real time today, and that's doing it the expensive way. I suppose the challenge is composting stuff from different processes every frame.
  - badsectoracula 3y ago
    It is not about performance/throughput. There are various factors at play: first of all, the synchronization is basically waiting for the monitor to finish displaying the last image before you send the new one. Second, unless the application takes over the screen (e.g. fullscreen games), the applications do not run in sync with the window system (and you do not want that because you do not want a single application to cause problems for other applications like hogging the screen updates). When you combine these two there is nothing really the application can do. As you wrote: > I suppose the challenge is composting stuff from different processes every frame. This is a significant part of the issue, though the fact that synchronization essentially means waiting is also another one (without synchronizing you get partial frames but those partial frames are still feedback for the user that makes the desktop feel more responsive).