[MPlayer-dev-eng] [PATCH] reduce flashing on resize with VDPAU

[Stephen Warren]

Uoti Urpala wrote:
> > Vdpau is missing a cancel queued surface, so it is not easy to remove an
> > already queued surface from the presentation queue - if we wanted to
> > drop an earlier frame.
> 
> This also sounds like a problem for UI functionality. If we use the same
> window for UI elements, does queuing multiple frames in the presentation
> queue mean we've committed to a significant period of time with zero UI
> responsiveness?

The functionality isn't missing; it doesn't make sense to have.

In any system where you queue surfaces for display, the length of the queue
Is going to be your OSD/UI latency. There's always a trade-off:

a) Very low (or zero) queue depth: Immediate (or fast) UI responsiveness,
but crappy video jitter due to the possibility of your app being scheduled
out at inopportune times, causing video to be delivered late.

b) Higher queue depth: Slower UI responsiveness (but we're typically only
talking a small handful of VSYNCs) but no video jitter, since the surfaces
are being dequeued/displayed in HW.

In either case (a) or (b) above, you'd never cancel display of a surface
in the queue; this would cause video stream drops, jerks in any animation
in the OSD/UI, etc.

Do note however, that the rate at which surfaces are pushed through the
presentation queue is 100% decoupled from the frame-rate of the video clip,
if any, being played. There's absolutely nothing stopping the app from
compositing a single decoded video picture into N different output surfaces,
so that the UI can run at e.g. 60Hz whilst the video runs at even 10Hz. I've
worked on a number of applications that work exactly this way. If using this
technique, UI latency is always precisely a function of VSYNC rate and queue
depth, and is orthogonal to video frame rate.

-- 
nvpublic