4 ms·
>why would you want tearing?! Avoiding tearing inevitably involves adding latency (the data is ready, render half a frame now or wait for vsync?) Some might co
by dTal 4y ago
>why would you want tearing?!
Avoiding tearing inevitably involves adding latency (the data is ready, render half a frame now or wait for vsync?) Some might consider it worthwhile to give up frame-perfection in exchange for getting as much data to the user as fast as possible; that's valid. Latency isn't just important for games, it colors every interaction we have with the computer.
- QUrprUd1nCeicw 4y agoThat's less and less relevant as GPUs and displays get faster. You might gain a trivial amount of latency in certain cases, with specific apps, at the cost of bringing back stuttering. The normal case is always going to be vsync. If your program is hardware accelerated it's not actually rendering "half frames," it draws the whole frame and the tearing you see is just a result of swapping at the wrong time. What I mean here is the rendering in clients isn't going to change either way, everything is already built to use vsync. Turning it off is more a matter of how many switches the compositor wants to provide for controlling the throttle. Most compositors should have support for fullscreen unredirect anyway, and that gets you most of the way there. EDIT: A few years ago this blog by Raph Levien sketched out a way to reduce latency without bringing back tearing, you may want to read it. https://raphlinus.github.io/ui/graphics/2020/09/13/compositor-is-evil.html https://raphlinus.github.io/ui/graphics/2020/09/13/composito...