Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Desktop compositing latency is real

lofibucket.com

Post reply on HN
Print view View original

211–220 of 306 posts

Re: Desktop compositing latency is real

#211

Post by jhasse »

kazinator wrote: post #209
raphlinus wrote: post #98

I've been experimenting with this too, in the context of the Windows front-end for xi editor. It's absolutely true that the compositor adds a frame of latency, but I have a very different take than "turn it off." First, it's possible to design an app around the compositor. Instead of sending a frame to the system, send a tree of layers. When updating the content or scrolling, just send a small delta to that tree. Fur…

In a text editor, we don't want to compose a whole frame just because a character was inserted. The situation of drawing directly into the visible frame buffer at any time we like without caring about V-sync is pretty much ideal. If the user inserts three characters very rapidly, but each draw has to wait 1/60th of a second for a V-sync, that will be visible.

> If the user inserts three characters very rapidly, but each draw has to wait 1/60th of a second for a V-sync, that will be visible.

A new character won't tricker a draw call though. Rather the three characters will queue up, added to an internal buffer and when the next draw is due, they will all three be drawn.

Re: Desktop compositing latency is real

#213

Post by raphlinus »

CyberDildonics wrote: post #207
raphlinus wrote: post #198

Earlier quoted context omitted.

Visual inspection for now. I've got an Arduino and a high-speed camera, so my plan for the next step is to send mouse and keyboard events from the Arduino, blinking an LED at the same time, then capture both the LED and the monitor in the video. Then a bit of image analysis. This is the only way to be quantitative and capture all the sources of latency.

The implication of what I was saying is that windows will always show the cursor lining up with the border of a window during resizing.

Would that it were so.

Re: Desktop compositing latency is real

#214

Post by [deleted] »

jhasse wrote: post #211
kazinator wrote: post #209

Earlier quoted context omitted.

In a text editor, we don't want to compose a whole frame just because a character was inserted. The situation of drawing directly into the visible frame buffer at any time we like without caring about V-sync is pretty much ideal. If the user inserts three characters very rapidly, but each draw has to wait 1/60th of a second for a V-sync, that will be visible.

> If the user inserts three characters very rapidly, but each draw has to wait 1/60th of a second for a V-sync, that will be visible. A new character won't tricker a draw call though. Rather the three characters will queue up, added to an internal buffer and when the next draw is due, they will all three be drawn.

[deleted]

Re: Desktop compositing latency is real

#215

Post by Sir_Cmpwn »

pmoriarty wrote: post #22

This article is about Windows, but I wonder how Wayland on Linux measures up.

It should be possible to reduce the latency quite a bit if a Wayland compositor had that goal in mind. It's something we're working on for Sway. Sometimes you have to choose beween (1) render correctly and (2) respond immediately to user feedback. When resizing windows for example, we can scale the old buffer up (stretching it) while we wait for a new buffer from the client, or we can wait to give you that feedback until the client has prepared a new buffer at the right size.

Re: Desktop compositing latency is real

#216

Post by Quarrelsome »

mfukar wrote: post #75
Quarrelsome wrote: post #46

sorry, so they had to write some code to test what they couldn't perceive but believe they can perceive? I feel like its plausible that this is partly a psychological problem?

Well, it does say > At least I can feel the difference when typing.

I can feel people's auras. Discuss.

Re: Desktop compositing latency is real

#217

Post by Sir_Cmpwn »

gciruelos wrote: post #212

i've been using sway[0] as my wm for some time now (it's a sort of port of i3 to wayland) and it's incredible that you can actually tell that it is much faster than wms running on X. [0] http://swaywm.org/

It's funny you mention this - it's only in the past few days that we've been taking this sort of thing more seriously, and our work is unreleased!

Re: Desktop compositing latency is real

#218

Post by modeless »

emn13 wrote: post #130

I will gladly believe this is a real problem, but this page does not demonstrate that (at least not convincingly); the metric used is simply too poor. To quote: > I used my own hacky measurement program written in C++ that sends a keypress to the application to be benchmarked. Then it waits until the character appears on screen. Virtual keypresses were sent with WinAPIs SendInput and pixels copied off screen with Bit…

The time measured is artificial but not necessarily uninteresting. You can't measure the true end to end latency this way, but you can compare different user applications to see how much latency they add. It's not perfect but it is the best available way to measure latency of arbitrary applications without extra hardware.

I built a browser latency benchmark based on a similar method: https://google.github.io/latency-benchmark/

I did plenty of testing and found that the measurements obtained this way do correlate with true hardware based latency measurement.

All that said, it is a travesty that modern OSes and hardware platforms do not provide the appropriate APIs to measure latency accurately. A lot of what is known about latency at low levels of the stack is thrown out before you get to the APIs available to applications.

Re: Desktop compositing latency is real

#219

Post by kazinator »

jhasse wrote: post #211
kazinator wrote: post #209

Earlier quoted context omitted.

In a text editor, we don't want to compose a whole frame just because a character was inserted. The situation of drawing directly into the visible frame buffer at any time we like without caring about V-sync is pretty much ideal. If the user inserts three characters very rapidly, but each draw has to wait 1/60th of a second for a V-sync, that will be visible.

> If the user inserts three characters very rapidly, but each draw has to wait 1/60th of a second for a V-sync, that will be visible. A new character won't tricker a draw call though. Rather the three characters will queue up, added to an internal buffer and when the next draw is due, they will all three be drawn.

That's how it should work. But when you look at the scatter plots, note how there are multiple bands under Windows 10. E.g. for gvim, not only is there an extra overall delay, but extra clusters of additional latency.

Re: Desktop compositing latency is real

#220

Post by falcolas »

StillBored wrote: post #166
falcolas wrote: post #126

Earlier quoted context omitted.

Requires a bigger chip (100+ IO pins) and more complex wiring diagrams than most inexpensive keyboard makers are willing to invest.

Replace with _any_ keyboard manufacture.. Similarly, while your keyboard may advertise USB2 or even USB3, the actual key-press USB interface is always running at USB 1 low speed (1.5Mbit). I spent a fair amount of time trying to find a keyboard to work on a device that I have that only works with high speed devices, 30 or 40 keyboards later I gave up... If someone actually knows of such a thing I would be interested.…

Likely because they want to implement the minimum necessary HID spec (or, in a nicer tone, the HID spec with the most compatibility), which would be the one supported by the BIOS.
Post reply on HN