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

201–210 of 306 posts

Re: Desktop compositing latency is real

#201

Post by raphlinus »

kevin_thibedeau wrote: post #161
pjc50 wrote: post #121

Earlier quoted context omitted.

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

The usecase mentioned in Jesse's talk (linked in my root comment) is displaying a notification from some other app while playing a game. They added the "flip_discard" swapchain effect so that the OS can paint the notification on top of the game content before flipping it in hardware. This is something of a hack; I think you're right that the endgame for this is that the hardware can indeed implement the full compositing stack. I'm not sure how far away we are from this.

Re: Desktop compositing latency is real

#202

Post by kevingadd »

nulagrithom wrote: post #196
cybermancy wrote: post #114

Earlier quoted context omitted.

This is because fullscreen mode allows the use of something called "DirectDraw Exclusive mode" which bypasses Windows for making calls to the GPU. https://msdn.microsoft.com/en-us/library/windows/desktop/dd3...

I wonder if it would be feasible to use this to reduce input lag in an editor?

Yes, but you lose access to any user interface components you don't paint yourself, and you can eat some lag/flickering when switching out of the app as control is returned to the compositor. If you end up needing to show the Open File picker from the OS or pop up the Print dialog you'll need to exit exclusive mode.

Re: Desktop compositing latency is real

#203

Post by kevingadd »

malbertife wrote: post #17
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.

What I hate even more is when I press the Windows key and start typing an application's name into the Start menu textbox, and it misses the first two or three keypresses.

That's weird, I don't have that problem. What build of Win10 are you running? I wonder if it depends on the kind of keyboard you're using.

Re: Desktop compositing latency is real

#204

Post by digi_owl »

tauio111 wrote: post #77

I always thought I was the only one noticing this. With Compositing enabled, both with DWM and on GNU/Linux, the whole interaction seems to become "soft" instead of the raw that feels much nicer and snappy. From my experience it also has to do with passing through the stack to the GPU when compositing, running it all from the CPU is what makes it feel snappy. I've also been researching about removing the triple buffe…

Makes me think of the "smooth scrolling" option that you can find in most web browsers. Never liked that, and first thing i hunt down after a new install.

This because using it feels like scrolling through molasses for whatever reason.

Re: Desktop compositing latency is real

#205

Post by kevingadd »

0xcde4c3db wrote: post #28
marcosdumay wrote: post #11

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.

This is a common source of delay in composited apps/games, yes. Ideally what you want is to have a completed frame ready for the compositor at least a few milliseconds before the next vertical sync arrives, but it's easy to screw that up, especially if you're getting fancy. Triple Buffering also enters the picture here (though mostly for games), because in the bad old days you had exactly two backbuffers, and if both were in use (one being scanned out to the monitor, the other your most recent completed frame) everything had to grind to a halt and wait before rendering or game code could continue. Triple buffering solved this by adding an extra frame, at the cost of an entire frame worth of display latency in exchange for your code spending less time spinning and waiting on the GPU. If someone is careless they could definitely end up with triple buffering enabled for their app (like if they're rendering using a media-oriented framework that turns it on.)

The 'Fast Sync' option NVIDIA added to their drivers in the last year or two is a fix for the triple buffering problem - you get spare buffers, but instead of adding a frame of latency the GPU always grabs the most recently completed frame for scanout. Of course, if a compositor is involved you now need the compositor to do this, and then for the compositor to utilize this feature when presenting a composited desktop to the GPU. I don't think any modern compositor does this at present.

Re: Desktop compositing latency is real

#207

Post by CyberDildonics »

raphlinus wrote: post #198
CyberDildonics wrote: post #165

Earlier quoted context omitted.

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.

Visual inspection for now. I've got an Arduino and a high-speed camera, so my plan for the next step is to send mouse and keyboard events from the Arduino, blinking an LED at the same time, then capture both the LED and the monitor in the video. Then a bit of image analysis. This is the only way to be quantitative and capture all the sources of latency.

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.

Re: Desktop compositing latency is real

#208

Post by xaqfox »

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…

A good (and easy to remember/no other affiliation) source for this data: https://displaylag.com/

Re: Desktop compositing latency is real

#209

Post by kazinator »

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…

In a text editor, we don't want to compose a whole frame just because a character was inserted. The situation of drawing directly into the visible frame buffer at any time we like without caring about V-sync is pretty much ideal. If the user inserts three characters very rapidly, but each draw has to wait 1/60th of a second for a V-sync, that will be visible.

Re: Desktop compositing latency is real

#210

Post by xaqfox »

jdmichal wrote: post #155
stoolpigeon wrote: post #147

Earlier quoted context omitted.

It's good to know that the person posting the link has a financial stake in it. Depending on the context this can mean a lot - like a review or recommendation.

Except it's Amazon. I could understand that position if it was a Dell affiliate link. But Amazon sells so many brands of monitors, any of which could carry the same affiliate code, that I don't see how that matters.

Just like the FTC, I do not care about the existence of the affiliate link being on HN, but only the disclosure. It makes for a fair(er) market.
Post reply on HN