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

[Stephen Warren]

Reimar Döffinger wrote:
> 
> On Sat, Mar 14, 2009 at 05:44:31PM +0100, Dan Oscarsson wrote:
> > In resize:
> >   - width and height are set to screen width and height.
> >     This results in no resizing of output surfaces are done but once.
> >     I suspect that destroying the active visible surface results in
> >     flashing - this avoids that.
> 
> That change does not really fix anything, it just hides the issue by
> making it less likely.

I haven't actually looked at the current MPlayer SVN codee, nor the patch,
but the NVIDIA's MPlayer patches made the output surfaces max(screen_size,
video_size), which I believe was the max window size except perhaps due to
manual resizing, which does then completely avoid the issue of color key
showing through.

> > In win_x11_init_vdpau_flip_queue:
> >   - set background colour to black for parts outside a surface.
> >     Without this I get yellowish flashing during resize. Black
> >     works better.
> 
> I heavily suggest that NVidia should change their code to set the
> background to bacl by default, making every application set that
> manually for no good reason just seems silly.
> Unless of course this is also the "overlay" colour as it was used for
> Xv, in that case this change might have weird effects like writing on a
> Window placed on top of MPlayer becoming transparent...

Apps can be coded to avoid the color key showing; that's what we assumed
they would do, rather than change the key color to something easy to 
accidentally trip.

> > In check_events:
> >   - removed the code that requeues the current visible output surface
> >     when paused. vdpau does redisplay the visible output surface by
> >     itself.
> 
> Are you sure this is true if the blit backend is used? I can't really
> see how, but of course NVidia might have found a clever trick I have not
> thought of.

The blit-based presentation queue doesn't redisplay on resize. However resize
doesn't erase the window content unless the window is set up wrong (only
covering the window with another will erase it).

Whilst it certainly would be theoretically possible for the blit-based
presentation queue to do the resize, since the surface is held on to until
the next is displayed, this isn't something we plan to implement.

-- 
nvpublic