As you mention, the solution does not solve the combined problem of both applications requiring minimum jitter and full rendering resources. Neither does unredirecting… (However unredirecting does reduce latency and resource usage for full-screen apps)

A possible solution would be to introduce selective triple-buffering for an application requiring full rendering resources. In this situation we only need to schedule redraw synchronously with VBlank (when damage) and can abandon the “urgent” concept. The maximum number of triple-buffers can be limited to one, as multiple applications requiring full rendering resources will be starved anyway.

A less resource heavy solution would be to prioritize the needs of the foreground application and always make the foreground application the “urgent” one. This would minimize both latency and jitter of the foreground application! I would personally be fine with both jitter and ratio-locked frame rates of the background applications, if only the foreground application ran perfectly.

A less radical compromise would be to only make an application “urgent” if it is both the foreground application and using full rendering resources. Then we can render synchronously with VBlank most of the time at the cost of slight latency of the foreground application.

Best regards, and thank you for improving our desktops

Windows could be using a hardware cursor without compositing and drawing the cursor in the compositor when that’s on. Or it could be updating the HW cursor position at the frame display VBlank with the mouse cursor position used for the window drag instead of the very latest cursor position. These aren’t distinguishable by observation.

In general, I don’t think that 16ms or even 33ms of latency in cursor position is observable to the naked eye *unless* you have two things to compare and can turn the time into a lag distance. If you are is using a Wacom Cintiq and can compare the pointer position exactly to the tip of the stylus, you are going to be very sensitive to latency in cursor position. If you can observe a 0-latency cursor vs. application drawing with latency you are going to notice. But getting down to less than a frame of latency for application drawing is hard because it’s just like audio – if you trim latency to a minimum, you have no margin for error and any disruption can cause skips.

I just find it curious how windows makes window dragging as low-latency as the cursor itself. Redrawing the window’s decoration, which has transparency and stuff, is definitely done by the compositor. The drawing of the cursor is just done by slapping on a bitmap, and I suspect that it is done independently of the compositor.
For weston, there is no lag in interactions with mouse movement (except a little in xwayland applications). Unfortunately the compositor does the drawing of the cursor and I believe that compared to X or Windows’ cursor drawing (“hardware” drawing), weston’s cursor lags by 1 frame.