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

101–110 of 306 posts

Re: Desktop compositing latency is real

#101

Post by qplex »

zaarn wrote: post #34
dingo_bat wrote: post #4

The data speaks for itself but I'm trying to perceive any latency in my Firefox (win10) and unable to. Typing seems instantaneous to me. I hate the milliseconds the start menu takes to animate though. Win7 start was instant.

From my experience latency is rarely bad when it's very very consistent. After some time the brain compensates. I do recall playing World of Tanks with a 800ms Ping. After about 3 months or so I was back to thinking there was no Ping until a problem with my ISP was fixed and I dropped to 8ms. After which I ran into walls a lot. The brain can adapt to such things rather well, given enough time.

I agree with you about consistency but 792ms is something though!

I remember when we upgraded from a 28.8k modem to ISDN. My Quake got a lot better purely because of lower latency. A friend was left behind on modem and he could tell the difference too, I was virtually unbeatable to him after the upgrade.

Of course we both knew that it was down to an unfair advantage so it wasn't a true victory.

Re: Desktop compositing latency is real

#102

Post by TheCoreh »

badsectoracula wrote: post #79
em3rgent0rdr wrote: post #45

Earlier quoted context omitted.

> "or GNU/Linux desktop" I believe Wayland has made some latency improvements.

Wayland uses a composition model which is inherently slower than having direct access to the front buffer.

Not necessarily: video output is ultimately limited by the display. If the display runs at, say, 60Hz and both drawing on an off-screen buffer and compositing together take up less than ~16ms, the result should be exactly the same as drawing directly on the front buffer.

The main problem is that modern GPU rendering is “pipelined”, so it's entirely possible to have a drawing operation that takes 16ms and a compositing operation that also takes 16ms, and still have your application running at 60FPS, albeit 1 frame "behind" the input. Most developers are not aware of that. (Including me, until recently. I learned about this while trying to figure out why my VR application felt "wobbly", despite running at the recommended 90FPS) The HTC Vive ships with a really neat tool for visualizing that: http://i.imgur.com/vqp01xn.png

Re: Desktop compositing latency is real

#103

Post by jakebasile »

Cthulhu_ wrote: post #18
deniska wrote: post #12

That's why I prefer to play games in fullscreen as opposed to "borderless windowed", I have noticed quite a bit of input lag in the latter mode.

It depends on the game for me, usually I prefer borderless windowed because I tend to alt-tab out a lot.

Me too. It's just so much quicker to alt-tab to my browser or Telegram or iTunes, even on my beefy rig it takes multiple seconds for my desktop to take control again.

In my experience the vast majority of games that I play don't suffer any perceptible ill effect from running in borderless fullscreen. If you're playing the game competitively it's another story, but for me running around shooting aliens in Destiny 2 or something I haven't noticed any degradation of my experience. There's of course the odd (usually older) game that doesn't support borderless fullscreen, but sometimes there are mods to support it.

Re: Desktop compositing latency is real

#104

Post by hasenj »

fredley wrote: post #37
Zardoz84 wrote: post #31

> Don’t you find it a bit funny that Windows 95 is actually snappier than Windows 10? It’s really a shame that response times in modern computers are visibly worse than those in twenty years ago. My Amiga A1200 (Only have extra RAM) feels faster and more responsive that any modern computer with Windows or GNU/Linux desktop.

Layers of abstraction take you further away from the metal. The more layers of abstraction your keypress must traverse before rendering is complete and the photons have reached your retina, the longer it will be until that happens. Layers of abstraction make complex tasks more reachable by a larger number of programmers by reducing the amount of specialist knowledge about those lower layers required to do the job. Th…

Consequently, we have more and more incompetent people writing software with absolutely no concerns about performance.

Re: Desktop compositing latency is real

#106

Post by cpburns2009 »

jdietrich wrote: post #91
lmm wrote: post #76

Earlier quoted context omitted.

The little plastic bits always snap off. Ethernet is great for semipermanent wires but not very good for peripherals like portable hard drives that are constantly disconnected and reconnected.

That problem is largely solved if you use 8P8C connectors with a rubber boot protecting the latching tab. https://info.pcboard.ca/wp-content/uploads/2017/04/RJ45-Conn...

Even with the protective guard the little plastic tabs inevitably break on me. I can't even say those have fared any better than the unprotected versions.

Re: Desktop compositing latency is real

#107

Post by nickjj »

mod wrote: post #99
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…

That's an affiliate link fwiw

It's true, but there's also a 4,000 word detailed blog post that describes how I came to pick that monitor along with giving you insights and tips on how to pick a different monitor if that one isn't for you.

Re: Desktop compositing latency is real

#108

Post by _pmf_ »

badsectoracula wrote: post #83
wruza wrote: post #56

Earlier quoted context omitted.

Numerous games, including those having complex graphics and behavior, can render 120+ frames per second and realtime interactions (physics, optics, reactions) on pretty average hardware. I don’t think that game scripters who make final things like scenery or ui face complexity much harder than those in gtk/qt/wpf/htmljs widget programming. Details would be interesting though, since I’m no game developer. If true, it…

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 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).

Modern UI toolkits (WPF, QML, JavaFX) operate on a scene graph, so they work exactly the same. Android is slowly catching up; it's a disgusting mix of the worst of both worlds.

Re: Desktop compositing latency is real

#109

Post by frik »

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)

Re: Desktop compositing latency is real

#110

Post by jws »

wolfgke wrote: post #90
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.

> 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. I don't claim that 15ms of lag is to be considered good, but the problem that one has to solve is debouncing the switches.

Denouncing shouldn’t add lag. On the first closure detection you can send the key down code. You then need some debounce logic to decide when to send the key up code, but after the key is solidly down you are again in a state to send the key up code as soon as the up begins.

The only time there should be lag is when a very short keypress happens, the key up might be delayed while the controller rules out bounce.

Post reply on HN