Originally Posted by uau
The test version always queues frames at time now + 10 seconds. On my machine the output looks like this:
Ah, that explains it.
The typical use-case for the presentation queue is to queue a few frames ahead *at 24-60Hz*. The reason for queueing frames ahead is to cover up and typically short-term latency in the system, application, GPU rendering, etc.
Queueing 10s ahead (in fact, queueing anything over 0.5s ahead is the value we picked) is an unusual situation.
Due to some implementation details in the blit-based presentation queue, events such as window movements "accelerate" any queued frames such that they are displayed immediately. When queueing e.g. 24-60Hz video, this will be noticed as a temporal glitch in the display for a short portion of time (e.g 1/3 s with max 8 frames queued at 24Hz). If the frames being queued are a significant time in the future, the effect will be significantly more noticeable; if the app queues at 0.1Hz, then you might end up with frames displayed at t=10, t=10.1 (should be t=20), t=30. To avoid this situation, any time we see a frame that should be displayed more than 0.5s in the future, the driver blocks until 0.5s before the timestamp before queueing the frame into the HW, to avoid significantly early display. The blocking itself is not a busy wait, but I suppose it could cause other parts of the driver, or other drivers, to busy-wait.
We could solve your issue simply by removing this "wait until close to the timestamp" behaviour. Would that be better than blocking here?