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

231–240 of 306 posts

Re: Desktop compositing latency is real

#231

Post by half-kh-hacker »

> your keyboard is already slower than you might expect.

An extract from the linked article:[0]

> A major source of latency is key travel time. It’s not a coincidence that the quickest keyboard measured also has the shortest key travel distance by a large margin.

They're not measuring from when the signal is sent from the keyboard, they're measuring from when the force begins to apply on the key. If you have a clicky or tactile switch (Cherry MX Blues, Greens, Browns, Clears, etc) then the latency measured here will be way disproportionate to how it actually /feels/.

[0]: https://danluu.com/keyboard-latency/

Re: Desktop compositing latency is real

#233

Post by em3rgent0rdr »

astrodust wrote: post #190
frik wrote: post #119

Earlier quoted context omitted.

Actually not a bad idea. Ethernet speed is one gigabit per second. And there are high throughput devices like LIDARs (eg Velodyne LiDAR known from Google/Waymo self-driving cars) that are connected via Ethernet rather than USB. Having 1 GBit Ethernet LAN network since 2004, I would prefer the possibility to upgrade to 10Gbit home Ethernet in near future.

It's a terrible idea. USB-3 is faster than 1Gbit/s. and there's no way you can drive a 5K monitor with any current or near future Ethernet standard, the bandwidth demands are too punishing. Ethernet isn't optimized around short-haul signals, like computer to screen over a few metres at most, it's for 100m+ runs in datacentres. The signals have to be a lot more durable.

> "USB-3 is faster than 1Gbit/s"

But Cat 6 Ethernet is 10 Gbit/s.

Re: Desktop compositing latency is real

#234

Post by z3t4 »

wruza wrote: post #56
fredley wrote: 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…

They would have problems rendering text though. I'm working on a text editor and made some research on the fastest way to render text. It's really hard to beat the OS API.

Re: Desktop compositing latency is real

#235

Post by wruza »

tormeh wrote: post #224
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…

I think you severely underestimate the difficulty of making a game engine.

I was not talking about making a low-level engine; I only theoretized that gamemaking is somewhat as hard as modern ui at the top level where you script it and “draw” 3d/2d ui or interaction parts. For fair comparison on that scale game engines should correspond to at least font and vector rendering like pango/ft or cairo, or even direct blit ops, not to widget positioning. For one example, it is pretty easy to take unity3d and make a 9pool game — it is just ~two hour tutorial on youtube for people with no cg background at all.

Re: Desktop compositing latency is real

#236

Post by badminton1 »

fra0 wrote: post #227
badminton1 wrote: post #194

If you want to have the most minimal Windows setup: - Don't use an antivirus - Stop unused services running in the background (e.g: services.msc) - Turn off all vision effects including compositing and animation Then you might want to set up a firewall to block all the nonsense like SMB, NetBIOS, etc. You can also set up a cheap old machine to act as your firewall, reverse proxy cache, antivirus/antispam, etc. You ca…

Pick up an LTSB release and remove the desktop (custom shell). It looks a lot like Arch / Debian with first class hardware support.

While LTSB looks good (fewer bundled apps, that's great), it is very dissimilar from Arch or Debian.

Regarding hardware compatibility, please be aware of the fact that Debian supports many more processor architectures than Windows.

Maybe Windows will support some peripherals better, but Linux has improved a lot in this respect. Chances are out of the box support for hardware is better in Linux than it is on Windows these days.

Re: Desktop compositing latency is real

#237

Post by wruza »

stult wrote: post #78
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…

It's a lot easier to optimize the APIs underlying those scripts because there are far fewer of them in even the most complicated video games than there are comparable abstractions in modern OSs. And there's more motivation. People accept the slightly lower responsiveness in normal OS interactions whereas even millisecond delays in competitive games are intolerable.

That said, whether hundreds of ms delays in OS are tolerable or not is a question on topic itself.

Re: Desktop compositing latency is real

#238

Post by wereHamster »

astrodust wrote: post #190
frik wrote: post #119

Earlier quoted context omitted.

Actually not a bad idea. Ethernet speed is one gigabit per second. And there are high throughput devices like LIDARs (eg Velodyne LiDAR known from Google/Waymo self-driving cars) that are connected via Ethernet rather than USB. Having 1 GBit Ethernet LAN network since 2004, I would prefer the possibility to upgrade to 10Gbit home Ethernet in near future.

It's a terrible idea. USB-3 is faster than 1Gbit/s. and there's no way you can drive a 5K monitor with any current or near future Ethernet standard, the bandwidth demands are too punishing. Ethernet isn't optimized around short-haul signals, like computer to screen over a few metres at most, it's for 100m+ runs in datacentres. The signals have to be a lot more durable.

> there's no way you can drive a 5K monitor with any current or near future Ethernet standard, the bandwidth demands are too punishing.

Really? You need more than 100gbit for 5k monitor? Because there is an 40/100gbit ethernet phy standard right now (has been for a while, since 2011). And work is being done on up to 200gbit (due to be ratified in late 2018).

Re: Desktop compositing latency is real

#239

Post by abiox »

p1esk wrote: post #189
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…

Why not go with 5k 27" monitor? http://www.dell.com/en-us/work/shop/cty/pdp/spd/dell-up2715k... Sure, it's over $1k, but if you're making $10k/mo writing code on it, then you should be able to afford it.

> if you're making $10k/mo writing code on it

hah... if only the world was silicon valley.

Re: Desktop compositing latency is real

#240

Post by wruza »

z3t4 wrote: post #234
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…

They would have problems rendering text though. I'm working on a text editor and made some research on the fastest way to render text. It's really hard to beat the OS API.

Good point, I also touched pango-level text rendering and can remember how long some layout calculations may take. Do things get better with DirectWrite/2D or is it just a facade to old techniques incompatible with game environments?

Edit: I also like how OSX go-fullscreen animation is done. They render new window once (with e.g. lots of text) completely in background and simply scale old window to fullscreen with alpha-transition between the two. First few frames give enough time for new window to be rendered and then it magically appears as being live-resized. I suspect few users actually notice the trick.

Post reply on HN