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

131–140 of 306 posts

Re: Desktop compositing latency is real

#131

Post by Flenser »

frik wrote: post #109
nickjj wrote: post #23

This is also why picking a good monitor is important for software development. Some monitors have tons of input lag (60-70ms) and that's the time it takes for you to see what you're typing to reach the display. This also includes the time it takes to see you move your mouse cursor too. I did a huge write up on picking a good monitor for development which can be found at: https://nickjanetakis.com/blog/how-to-pick-a-g…

If you are looking for such monitors, look for gaming monitors with TN-panel, with 2ms or 4ms response time. Compared to office monitors or even TVs there is a big difference. (mind that TN-panel have pro and cons)

What happens if you have multiple monitors? i.e. a TN-panel for gaming and an IPS for graphic design?

Re: Desktop compositing latency is real

#132

Post by looiid »

vetinari wrote: post #86
fhood wrote: post #81

Earlier quoted context omitted.

Could someone explain to me why on earth 15ms of lag for a key press is considered good? It is a switch for gods sake. It should be near instant.

The linked article explains it (TLDR: key travel time, scanning keyboard matrix, debouncing).

It’s a common myth that denouncing needs to meaningfully affect latency. It does not. It will affect maximum repeat rate, but you can pretty much report an event the moment you see an edge.

Re: Desktop compositing latency is real

#133

Post by mzzter »

Smartphones suffer from input latency too, though I’m unsure of the underlying cause (curious how iOS handles window/view drawing). It only seems to be getting worse, though I haven’t done tests on this. While each new model undoubtedly has better tech specs, the interface responsiveness doesn’t seem to improve.

Re: Desktop compositing latency is real

#134

Post by thomasahle »

Jasper_ wrote: post #116
83457 wrote: post #33

Earlier quoted context omitted.

"I can send an IP packet to Europe faster than I can send a pixel to the screen. How f’d up is that?" - John Carmack

Right, the issue is that 60Hz is ridiculously slow. Ethernet hardware is multiple orders of magnitude faster. It's just because of broadcast TV and CRT legacy. G-Sync / FreeSync allow up to 240Hz, which is ~4ms latency.

60Hz is 16.7ms between each picture. However, that only gives you a lower bound on the latency. The actual time from GPU sending picture, to picture being on screen, can be a lot more. See the John Carmack answer above.

Re: Desktop compositing latency is real

#135

Post by noir_lord »

frik wrote: post #109
nickjj wrote: post #23

This is also why picking a good monitor is important for software development. Some monitors have tons of input lag (60-70ms) and that's the time it takes for you to see what you're typing to reach the display. This also includes the time it takes to see you move your mouse cursor too. I did a huge write up on picking a good monitor for development which can be found at: https://nickjanetakis.com/blog/how-to-pick-a-g…

If you are looking for such monitors, look for gaming monitors with TN-panel, with 2ms or 4ms response time. Compared to office monitors or even TVs there is a big difference. (mind that TN-panel have pro and cons)

Much worse viewing angles is a pain.

Re: Desktop compositing latency is real

#136

Post by krylon »

My work laptop (the only Windows computer I use) runs Windows 7, and I intend to keep it that way as long as Windows 7 still gets updates. This article just confirms my bias, and I freely admit I am biased. I do not like Windows very much to begin with, but as far as Windows goes, I think Windows 7 ____ing nailed it (for people without touchscreens, anyway).

On a related note, I have noticed that Outlook 2013 exhibits a notable lag between a keystroke and a character appearing in the message window. I have not done any measurements, but my best guess is that it is in the order of hundreds of milliseconds. If you type fast (I like to think that I do), Outlook can keep up throughput-wise, but this lag is terribly annoying.

Re: Desktop compositing latency is real

#137

Post by willglynn »

solotronics wrote: post #52
em3rgent0rdr wrote: post #48

Earlier quoted context omitted.

this reminds me of the argument that instead of going to USB C 3.1 as the grand unifying connector for all peripherals (including video), we should have instead migrated to Ethernet cables for everything.

ethernet over multimode fiber, I want to be able to have accessories hundreds of meters away from my computer

Careful, multi-mode fiber is near its scaling limits. 10GBASE-SR and 25GBASE-SR exist, but that's about it. (By contrast, 40GBASE-LR and 100GBASE-LR work over single-mode fiber, and DWDM + coherent optics can push the medium much further.) Wouldn't want to be stuck at 25 gbps forever ;-)

Re: Desktop compositing latency is real

#139

Post by mschuster91 »

krylon wrote: post #136

My work laptop (the only Windows computer I use) runs Windows 7, and I intend to keep it that way as long as Windows 7 still gets updates. This article just confirms my bias, and I freely admit I am biased. I do not like Windows very much to begin with, but as far as Windows goes, I think Windows 7 ____ing nailed it (for people without touchscreens, anyway). On a related note, I have noticed that Outlook 2013 exhibit…

> On a related note, I have noticed that Outlook 2013 exhibits a notable lag between a keystroke and a character appearing in the message window.

Try switching to text-only mails, no zoom... and if you must write HTML mails, do not have an image that is larger size than the window. As soon as there is an image that doesn't fit into the window at 100% zoom Outlook begins to crawl.

Re: Desktop compositing latency is real

#140

Post by badsectoracula »

Jasper_ wrote: post #112
badsectoracula wrote: post #83

Earlier quoted context omitted.

There isn't much of a difference between a GUI toolkit you'd find in a desktop application and the GUI framework you'd see in a game - the most likely difference will be that the game GUI will be redrawn every frame whereas the desktop GUI wont (and there are game GUI frameworks that cache their output to avoid redrawing the entire widget tree every frame). The difference when it comes to why games can be snappier is…

The reason that apps on Windows can bypass the compositor is that you can use them as the scanout buffer directly on fullscreen. On Linux (both Xorg and Wayland), this same exact behavior is supported with a compositor. For strange legacy reasons, it's known as "fullscreen unredirection". If you're running windowed on all three OSes, you see the same compositor latency.

Note that on Linux you are not forced to use a compositor, personally i do not use one and so i do not have any such penalty when running games in windowed mode.
Post reply on HN