> Could compositors be optimised to eliminate the extra frame of lag in the case where every window on-screen is being displayed “directly” by invisibly switching to a mode that maps each scanline and pixel column to a window’s framebuffer
Yes. This concept is called hardware overlays and there are varying levels of support for it in different GPUs and compositors.
There are tradeoffs. Using multiple hardware overlays may cost extra power and/or memory bandwidth, the number of supported overlays may be very limited, alpha blending may not be supported, and the transforms that can be applied to overlays may be very limited. The extremely hardware specific nature of the restrictions and the lack of good APIs exposing overlays means they get much less use than they should.
Technically if your pixel operation is commutative and reversible (as could be with alpha blending), you could store a buffer of pixels at the current position, then undo the previous pixel by current window at that buffer and then re-apply the operation with the new pixel value, and then directly send this to the display?
Am I missing something apart from the fact that alpha blending is not actually commutative and/or reversible; and the fact that nobody implemented this yet?
Yes. This concept is called hardware overlays and there are varying levels of support for it in different GPUs and compositors.
There are tradeoffs. Using multiple hardware overlays may cost extra power and/or memory bandwidth, the number of supported overlays may be very limited, alpha blending may not be supported, and the transforms that can be applied to overlays may be very limited. The extremely hardware specific nature of the restrictions and the lack of good APIs exposing overlays means they get much less use than they should.