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

161–170 of 306 posts

Re: Desktop compositing latency is real

#161

Post by kevin_thibedeau »

pjc50 wrote: post #121
raphlinus wrote: post #98

I've been experimenting with this too, in the context of the Windows front-end for xi editor. It's absolutely true that the compositor adds a frame of latency, but I have a very different take than "turn it off." First, it's possible to design an app around the compositor. Instead of sending a frame to the system, send a tree of layers. When updating the content or scrolling, just send a small delta to that tree. Fur…

> Instead of sending a frame to the system, send a tree of layers. Which API does one use to do this? I'm slightly surprised that hardware overlays aren't already a feature, especially given that they're handled by the graphics card. I know there's a special API for video overlay, especially DRM video (where part of the requirement is that the system doesn't allow it near the compositor where it could be screenshotte…

People generally aren't composing other effects on top of a video overlay. Making it work in the general case requires hardware that can do all the things the compositing engine is doing in software.

Re: Desktop compositing latency is real

#162

Post by TickleSteve »

NickM wrote: post #94
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…

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. The more layers of abstraction you have, the less they have to worry about lower levels and can just get on with what they want to do. Sometimes this is certainly true, but I think when it comes to abstraction layers, people tend to o…

Well said...

It wouldn't be so bad if the many layers of abstractions actually resulted in increased productivity, but they clearly don't.

Simplicity >> abstractions.

Re: Desktop compositing latency is real

#164

Post by jandrese »

frik wrote: post #109
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)

The problem is:

TN Panel:

Pro: Cheap, low latency

Con: Everything else

Re: Desktop compositing latency is real

#165

Post by CyberDildonics »

raphlinus wrote: post #98

I've been experimenting with this too, in the context of the Windows front-end for xi editor. It's absolutely true that the compositor adds a frame of latency, but I have a very different take than "turn it off." First, it's possible to design an app around the compositor. Instead of sending a frame to the system, send a tree of layers. When updating the content or scrolling, just send a small delta to that tree. Fur…

How are you testing the mouse cursor following the window borders on resize? I've read that windows turns off the hardware sprite mouse cursor when resizing windows so that it can software render it to always line up properly.

Re: Desktop compositing latency is real

#166

Post by StillBored »

falcolas wrote: post #126
madez wrote: post #100

Earlier quoted context omitted.

A keyboard doesn't need to implement a scanning matrix. It could hook up all keys individually to a an own IO-Port.

Requires a bigger chip (100+ IO pins) and more complex wiring diagrams than most inexpensive keyboard makers are willing to invest.

Replace with _any_ keyboard manufacture.. Similarly, while your keyboard may advertise USB2 or even USB3, the actual key-press USB interface is always running at USB 1 low speed (1.5Mbit).

I spent a fair amount of time trying to find a keyboard to work on a device that I have that only works with high speed devices, 30 or 40 keyboards later I gave up... If someone actually knows of such a thing I would be interested. Same basic problem with mice.. I guess the thought-process is that hey USB2 supports split transactions, and the keyboard/mouse won't actually generate even 1.5M bit of data, so we are going to continue to sell the same basic mouse/keyboard interfaces we were selling 20 years ago wrapped in styling variations.

PS: Some of the physical button keyboards I found with configurable colors/etc, usb hubs, do support USB3... For the color controls, or hub. The keyboard endpoint is still at low speed...

Re: Desktop compositing latency is real

#167

Post by pcwalton »

srcmap wrote: post #35

According to this: https://www.youtube.com/watch?v=BTURkjYJ_uk Firefox's servo engine can compose CSS elements/Display List together at 500 frames / second. Maybe next version of Windows / Linux desktop should use FF's servo engine?

Thanks for the kind words :) But that was an artificial benchmarking mode that turned off any synchronization. It couldn't actually show the picture at hundreds of FPS, because the physical hardware can only update at 60.

Re: Desktop compositing latency is real

#168

Post by CyberDildonics »

pcwalton wrote: post #159
raphlinus wrote: post #98

I've been experimenting with this too, in the context of the Windows front-end for xi editor. It's absolutely true that the compositor adds a frame of latency, but I have a very different take than "turn it off." First, it's possible to design an app around the compositor. Instead of sending a frame to the system, send a tree of layers. When updating the content or scrolling, just send a small delta to that tree. Fur…

The issue with sending a tree of layers is that this prevents some important optimizations: avoiding overdraw with early Z becomes impossible, because your app doesn't know anything about the positions of the scrollable layers and so has to be conservative and paint all of their contents. So you trade a frame of latency for lots of overdraw, which is a tradeoff I'm not really comfortable making. (Note that today, alm…

> So you trade a frame of latency for lots of overdraw, which is a tradeoff I'm not really comfortable making.

I would jump at the chance to make that trade. My 8 year old CPU is rarely taxed by normal usage. What's the point in having a faster computer if it feels slower?

Re: Desktop compositing latency is real

#169

Post by leeter »

jsd1982 wrote: post #124

> Virtual keypresses were sent with WinAPIs SendInput and pixels copied off screen with BitBlt. This methodology alone could account for the differences in timing between Win7 and Win10. For all we know, Win10 could just be slower at getting the pixels back to the program from BitBlt, or SendInput could be slower triggering events, or a multitude of other issues. The best way to truly detect key-to-photon latency is…

I'd be curious to see message traces and UMAPC (user mode asynchronous procedure calls) traces of this between the two. My hypothesis is that Win10 does quite a bit more in UMAPCs than win7 does in the interests of keeping the system 'responsive' even at the costs of latency. For those not aware UMAPCs only run when a thread is available in an 'alertable' state (see MSDN as that's not exactly simple to explain https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... ), as such they tend to wait for input or other runtime idle points unless the application makes very heavy use of windows built in asynchronous methods and alertable waits.

I would also be curious to compare a D2D application versus a GDI application; as the majority of the work has gone to D2D in the last few years. Please note that D2D application in this case means one using a swap chain and device not an ID2DHWNDRenderTarget (this rasterizes and composites on the GPU but has GDI compatibility built in).

Re: Desktop compositing latency is real

#170

Post by beardbandit »

noir_lord wrote: post #135
frik wrote: post #109

Earlier quoted context omitted.

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)

Much worse viewing angles is a pain.

I agree.

Which is why its hilarious whenever I ask around for recommendations, especially on Reddit, everyone tries to peg it as a non issue. As if your head never moves and you only have one monitor.

Post reply on HN