Live data from Hacker News

Desktop compositing latency is real

lofibucket.com

301–306 of 306 posts

Re: Desktop compositing latency is real

#302
post #289

Earlier quoted context omitted.

It's not just monitors even keyboards can have 40+ms worth of delay and it all adds up.

I don't think that was what he was referring to

"I video record showing both the game controller and the screen with a 240 fps camera" https://superuser.com/q/419070/2269

So, it's total response times from key press on a game controller to screen that is important not individual components. Sure, 0.04 seconds on it's own is not a big deal, but when 5 or six things take 0.04 seconds you hit noticeable delays.

Re: Desktop compositing latency is real

#303
post #301

Earlier quoted context omitted.

I can feel people's auras. Discuss.

I suspect you know what 'feel' and 'perceive' mean, and just being quarrelsome.

I'm suggesting its in their head and they can't actually feel or perceive it.

Re: Desktop compositing latency is real

#304

Earlier quoted context omitted.

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.

Still not as fast as USB-3+Thunderbolt which is already 40Gbit/s and intended to be pushed to at least 80Gbit/s to support 8K screens.

Re: Desktop compositing latency is real

#305

Earlier quoted context omitted.

The implication of what I was saying is that windows will always show the cursor lining up with the border of a window during resizing.

Would that it were so.

Hmm, are you inspired or were part of https://github.com/google/walt ?

Re: Desktop compositing latency is real

#306

Earlier quoted context omitted.

That seems like a dubious claim to me. In my experience maxing out memory or pcie bandwidth is rarely a bottleneck, and extremely unlikely / impossible with low CPU usage. Do you have a link or more detail about 'already cramped pipelines'?

2D rendering on GPUs is almost entirely memory bound. Source: I've been working on GPU 2D rendering full time for years now.

Depends heavily on the GPU and the scene being rendered. On Android I've seen low-end GPUs bottlenecked by the shader ALU of all things, even though the 2D renderer only produces trivial shaders. Turns out it's easier to whack off shader compute cores than it is to muck with the memory bus in some cases.

Most common situation is the GPU isn't taxed at all, though, and doesn't even leave idle clocks. We end up just being limited by GL draw call overhead.

Post reply on HN