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

61–70 of 306 posts

Re: Desktop compositing latency is real

#61

Post by mhd »

83457 wrote: post #19
ahartmetz wrote: post #7

I recently measured it with my phone's camera in slow motion mode. The system is an AMD Ryzen 1800X with AMD R9 280x GPU, KDE Plasma with KWin window manager in compositing mode. Key press to screen output latency was ~33 millseconds (90 fps recording, so increments of 11) in KWrite. The computer feels plenty responsive with that latency, and I hate latency... It is a full stack real world result - for comparison pur…

How are you measuring from key activation?

Yeah, that seems to be a weak point of some visual measurements, especially when laptop and other scissor keyboards score better than older switch-based ones.

Re: Desktop compositing latency is real

#62

Post by nickjj »

ino wrote: post #29
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…

I have the same monitor and it's pretty good. The only thing I don't quite like is the pixel size, it's a bit small for native scaling. I kind of wish i had gone for the 27". I went with two 25" because two 27" were a bit too big for me.

Do you have 20/20 vision?

With glasses (20/20) I can comfortably read text from up to 3 feet away from the 25" version at 1:1 scaling. Even tiny text like the HN text field box.

Re: Desktop compositing latency is real

#63

Post by vetinari »

acdha wrote: post #40
vetinari wrote: post #20

Earlier quoted context omitted.

33 ms is two frames, if your monitor is at 60 Hz. If you tried vscode or other electron app, it might be 49 ms (3 frames). These are the numbers I'm getting from 1900X with Nvidia 1080 GPU, Gnome3, 4k@60hz, but without measuring latency of the keyboard itself. Modern keyboards are another part of the problem. They can also take their sweet time since keypress until packet appears at the USB bus. See https://danluu.co…

For reference, on a 2012 MacBook Air the numbers are 18-20ms in either a regular app or VSCode.

I'm getting min 18.5-avg 24.3-max 35.2 ms in vscode on 2015 rMBP. However, the test won't finish and Typometer complains ("Previously undetected block cursor found"). In Emacs, it won't run at all.

Re: Desktop compositing latency is real

#64

Post by vetinari »

floatboth wrote: post #49
vetinari wrote: post #20

Earlier quoted context omitted.

33 ms is two frames, if your monitor is at 60 Hz. If you tried vscode or other electron app, it might be 49 ms (3 frames). These are the numbers I'm getting from 1900X with Nvidia 1080 GPU, Gnome3, 4k@60hz, but without measuring latency of the keyboard itself. Modern keyboards are another part of the problem. They can also take their sweet time since keypress until packet appears at the USB bus. See https://danluu.co…

Modern motherboards often still have a PS/2 port! And most USB keyboards still support PS/2, a passive adapter works great.

The problem is often in keyboard controller, not in the interface. Apple managed to get fastest keyboard with only 15ms lag; other may be order of magnitude slower.

Re: Desktop compositing latency is real

#65

Post by OnACoffeeBreak »

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

Just make sure those cables are never bent beyond the minimum bend radius.

Re: Desktop compositing latency is real

#66

Post by sandyarmstrong »

raverbashing wrote: post #57
forgotmypw wrote: post #43

Someone recently gave me an old PowerBook G3, running Mac OS 8.6. I was amazed by how responsive the UI is compared to today's UIs, from Mac to Windows to iOS to Android. When I clicked something, it felt like there was a pushrod between the mouse button and the menu, which triggered it instantly.

Well compositing was introduced in 10.2, I'm not sure if running Classic Mac OS was an advantage in this case

Did you use OS X prior to 10.2? I guarantee you it was slower and worse in every way. Especially compared to classic. There is a reason they continued installing OS 9 side-by-side before 10.2.

Re: Desktop compositing latency is real

#68

Post by dilap »

em3rgent0rdr wrote: post #48
pjc50 wrote: post #41

Earlier quoted context omitted.

Solution: send the pixel to the screen over IP! (joking, but with a tiny serious element)

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.

in all seriousness, why not?

Re: Desktop compositing latency is real

#69

Post by galad87 »

sandyarmstrong wrote: post #66
raverbashing wrote: post #57

Earlier quoted context omitted.

Well compositing was introduced in 10.2, I'm not sure if running Classic Mac OS was an advantage in this case

Did you use OS X prior to 10.2? I guarantee you it was slower and worse in every way. Especially compared to classic. There is a reason they continued installing OS 9 side-by-side before 10.2.

OS X did compositing on the cpu before Quartz Extreme in 10.2

Re: Desktop compositing latency is real

#70

Post by jheriko »

the argument about vsync and framebuffers seems mistaken. vsync only prevents partial renderers, not full renders, so disabling it does not remove latency in most cases,

this article makes it sound like there is some magical way to draw directly into the buffer without it being redrawn, which is not true. the best you can get is a chance of faster drawing because you can write into the buffer is its being drawn... (and probably get some tearing)

the idea that compositing is somehow slower is also very misleading... how exactly is a stacked renderer faster?

i think the author is blaming a poor implementation on technical details that they only partly understand.

Post reply on HN