5 ms·

Any window compositor add UI latency to avoid screen tearing.

by pmarin 7y ago

sliken 7y ago
Sure, but things have progressed quite a bit since XLIB. After all it's designed for high latency/low bandwidth network connections using an ancient protocol with all kinds of caching, complexity, and vector oriented UIs out of tech with today's mostly bitmapped UIs. There's something crazy like 64 ways to join to vectors. 100s of dot/dash combinations for drawing a line, caching of color maps, etc. etc. etc.
- DonHopkins 7y ago
  X11 is hardly vector oriented. You can draw lines and ovals, but the graphics model itself is totally pixel oriented. See the 'X-Windows Disaster' section 'Myth: X is "Device Independent"': https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47#9d2d https://medium.com/@donhopkins/the-x-windows-disaster-128d39... Myth: X is “Device Independent” X is extremely device dependent because all X graphics are specified in pixel coordinates. Graphics drawn on different resolution screens come out at different sizes, so you have to scale all the coordinates yourself if you want to draw at a certain size. Not all screens even have square pixels: unless you don’t mind rectangular squares and oval circles, you also have to adjust all coordinates according to the pixel aspect ratio. A task as simple as filing and stroking shapes is quite complicated because of X’s bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra “bonus pixels” when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that “in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion).” This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can’t even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses even though you scaled the rectangle corner coordinates to compensate for the aspect ratio.
vardump 7y ago
But not necessarily more than strictly needed for avoiding tearing. If you can read current scanline and have per window swap chain (hardware layer), it might be possible to completely avoid UI latency and tearing by drawing just before scanout. Apart from latency introduced by the display device itself. Of course it might tear if the scanline chasing drawing thread is context switched away at a bad moment. This technique is explained better at [0]. The point is mainly that you can combine this with GPU hardware multiple swap chains (layers). This is never going to be a general solution, though. Just for some special cases where it's both possible to draw fast enough to chase current scanline. Also not all GPUs have multiple swap chains available per display. [0]: https://www.blurbusters.com/blur-busters-lagless-raster-follower-algorithm-for-emulator-developers/ https://www.blurbusters.com/blur-busters-lagless-raster-foll...

Any window compositor add UI latency to avoid screen tearing.

by pmarin 7y ago

Any window compositor add UI latency to avoid screen tearing.

Sure, but things have progressed quite a bit since XLIB. After all it's designed for high latency/low bandwidth network connections using an ancient protocol with all kinds of caching, complexity, and vector oriented UIs out of tech with today's mostly bitmapped UIs. There's something crazy like 64 ways to join to vectors. 100s of dot/dash combinations for drawing a line, caching of color maps, etc. etc. etc.

DonHopkins 7y ago
X11 is hardly vector oriented. You can draw lines and ovals, but the graphics model itself is totally pixel oriented. See the 'X-Windows Disaster' section 'Myth: X is "Device Independent"': https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47#9d2d https://medium.com/@donhopkins/the-x-windows-disaster-128d39... Myth: X is “Device Independent” X is extremely device dependent because all X graphics are specified in pixel coordinates. Graphics drawn on different resolution screens come out at different sizes, so you have to scale all the coordinates yourself if you want to draw at a certain size. Not all screens even have square pixels: unless you don’t mind rectangular squares and oval circles, you also have to adjust all coordinates according to the pixel aspect ratio. A task as simple as filing and stroking shapes is quite complicated because of X’s bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra “bonus pixels” when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that “in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion).” This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can’t even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses even though you scaled the rectangle corner coordinates to compensate for the aspect ratio.

vardump 7y ago

But not necessarily more than strictly needed for avoiding tearing. If you can read current scanline and have per window swap chain (hardware layer), it might be possible to completely avoid UI latency and tearing by drawing just before scanout. Apart from latency introduced by the display device itself. Of course it might tear if the scanline chasing drawing thread is context switched away at a bad moment. This technique is explained better at [0]. The point is mainly that you can combine this with GPU hardware multiple swap chains (layers). This is never going to be a general solution, though. Just for some special cases where it's both possible to draw fast enough to chase current scanline. Also not all GPUs have multiple swap chains available per display. [0]: https://www.blurbusters.com/blur-busters-lagless-raster-follower-algorithm-for-emulator-developers/ https://www.blurbusters.com/blur-busters-lagless-raster-foll...