3 ms·

Under normal circumstances Windows' DWM compositor will avoid compositing at the display rate if nothing has changed. It used to be pretty easy to demonstrate t

Under normal circumstances Windows' DWM compositor will avoid compositing at the display rate if nothing has changed. It used to be pretty easy to demonstrate this by using a hook application (like fraps) to put a framerate overlay on DWM, though I don't think that works anymore. If you have g-sync enabled for the active windowed application, the DWM composition rate (and the monitor scanout as a whole) will be tied to the windowed application's vsync, so if it's running at 30hz so is your desktop until you tab away. Many G-Sync monitors have a built in framerate overlay you can toggle on to observe this (though the lag on your mouse cursor will make it obvious). I suspect in practice most software is not very good at giving the compositor the info it needs to avoid wasteful refreshes of the whole desktop, and the compositor probably also isn't putting in as much effort as it could.

formerly_proven 6y ago
That's a good point I totally forgot about. It actually means that most of the infrastructure for this is already around and implemented, but of course fundamentally this is an information problem - the compositor gets told when applications "damaged" their output, but since there is no concept of presenting a frame in these legacy 2D APIs (GDI/+, X11 etc.), the compositor has no idea if the application will continuing "damaging" its output, or if it is "done for now". I think the best a compositor might be able to do is something along the lines of keeping track of the latest possible time it has to start rendering such that the frame can be swapped to the front and sent to the screen. This should result in the lowest possible average latency while rendering at the vsync rate. DWM is clearly not doing this (since the delay is discretized to 16.7/33 ms), the Linux might be doing this, or it might be rendering on every damage event and use triple buffering, either would be plausibel given the 8 ms average delay.

formerly_proven 6y ago

That's a good point I totally forgot about. It actually means that most of the infrastructure for this is already around and implemented, but of course fundamentally this is an information problem - the compositor gets told when applications "damaged" their output, but since there is no concept of presenting a frame in these legacy 2D APIs (GDI/+, X11 etc.), the compositor has no idea if the application will continuing "damaging" its output, or if it is "done for now". I think the best a compositor might be able to do is something along the lines of keeping track of the latest possible time it has to start rendering such that the frame can be swapped to the front and sent to the screen. This should result in the lowest possible average latency while rendering at the vsync rate. DWM is clearly not doing this (since the delay is discretized to 16.7/33 ms), the Linux might be doing this, or it might be rendering on every damage event and use triple buffering, either would be plausibel given the 8 ms average delay.