Live data from Hacker News

Desktop compositing latency is real

lofibucket.com

81–90 of 306 posts

Re: Desktop compositing latency is real

#81

Earlier quoted context omitted.

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.

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.

Re: Desktop compositing latency is real

#82

Why would enforcing vsync add more than 1/60s of latency to anything? This looks way more like badly designed animations than some fundamental problem coming from the hardware.

Perhaps it ends up being multiple vsync waits for a given rendered frame? Something like the application or OpenGL driver waiting for vsync before rendering into its buffer, then the compositor waiting for the next vsync before actually compositing/flipping.

I see. Locking everything until you get a vsync surely makes the code simpler.

I fill that as about as likely as hardcoding the frames of animations, and displaying them all whatever device frequency you have.

Re: Desktop compositing latency is real

#83
post #56
post #37

Earlier quoted context omitted.

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…

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 that games are "allowed" to bypass most of the layers and cruft that exists between the user and the hardware, including the compositor that the linked article is talking about (in Windows at least).

Fortunately in Linux with Xorg you can get stuff on screen as fast as the code can ask for it, as long as you are not using a compositor (so you can even play games in a window with no additional lag!).

Hopefully the Wayland mania wont get to kill Xorg since yet another issue Wayland has and X11 doesn't is that with Wayland you are forced in a composition model.

Re: Desktop compositing latency is real

#84
post #37

> 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…

[deleted]

Re: Desktop compositing latency is real

#85
post #6

> Don’t you find it a bit funny that Windows 95 is actually snappier than Windows 10? Comparing them on the same hardware?

Try popping the start menu open on a Windows 10 machine with a mechanical hard drive.

It wasn't much better on Windows 95 on average hardware around the time of the release of Windows 95. Heck, if you dared click [Start] as soon as the desktop displayed (read: Windows hadn't yet finished booting) then the whole OS would hang for several minutes.

Re: Desktop compositing latency is real

#86
post #81

Earlier quoted context omitted.

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.

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

Re: Desktop compositing latency is real

#87
post #76
post #68

Earlier quoted context omitted.

in all seriousness, why not?

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.

What’s that to do with displays which aren’t unplugged frequently?

Re: Desktop compositing latency is real

#88
post #74
post #68

Earlier quoted context omitted.

in all seriousness, why not?

The obvious ones: Ethernet cables are big (imagine one on a phone), and aren't designed to be plugged and unplugged the massive number of times that USB cables are (spring contacts wear out, little clips break).

USB cables have little to do with the question of sending pixels via IP

Outside HDMI and some DisplayPort cables, all display connectors click or screw in

And we’re talking about desktop OS and displays

Re: Desktop compositing latency is real

#89
> Actually, I don’t know why a compositing window manager should enforce V-Sync anyway? Obviously you get screen tearing without it but the option should still be there for those who want it.

Every additional option (especially in the realm of video settings) opens the door for additional complexity, implementation error, and user error in unintentionally setting the undesired mode. It's perfectly understandable why window managers would settle on one or the other of two extremely different render-to-screen approaches, especially when general consensus for quite some time now in the graphics space has been that minimizing the potential for tearing is preferable.

Re: Desktop compositing latency is real

#90
post #81

Earlier quoted context omitted.

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.

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.

Post reply on HN