[MPlayer-dev-eng] Re: [PATCH] VFCTRL_PERIODIC_UPDATE

[Uoti Urpala]

On Tue, 2007-01-23 at 21:57 +0100, Michael Niedermayer wrote:
> On Tue, Jan 23, 2007 at 05:04:20PM +0200, Uoti Urpala wrote:
> > On Tue, 2007-01-23 at 08:39 -0500, Jason Tackaberry wrote:
> > > Right, being vo-independent is a requirement.  
> > 
> > A requirement for what? If you were willing to require -nodouble then
> > requiring a particular vo (or one of a few alternatives) should be minor
> > in comparison...
> 
> i very strongly vote for a vo-independent solution (=one which works with
> all VOs)

Are you sure you understand what you're voting about? Almost everything
in this whole thread is about features to support updating the overlay
more often than once per frame; parts of your post sound like you might
have missed that. Or perhaps you omitted too much of exactly what you
mean by "a vo-independent solution".

> and IMHO being able to have a filter after the overlay is a much cooler
> feature then some 1/30 second delay caused by inaccessibility of a second
> buffer in double buffering

This part doesn't seem to make sense; obviously "delay" isn't a feature.
If you mean "ability to have a filter after ... is worth a 1/30 second
delay", then exactly what kind of alternative implementation are you
thinking about which would have those features?

> i also would like to point at the fact that these VO buffers may not be
> readable (=insanely slow due to the hw not being designed for reading)
> which would make a blend in VO memory a hopelessly stupid idea

I'm perfectly aware that some VOs might require caching the image
separately to allow updating it. However I don't think that is normally
the case with xv for example, and the non-ass subtitle/OSD code already
does blending in VO memory in some VOs. Do you think the existing OSD
code is "hopelessly stupid"? I haven't heard complaints about its
performance.

> and there may be more then just 2 buffers which might complicate things

I don't think that would cause complications in this case.

> and theres yet another problem, if you blend into the vissible buffer
> then double buffering becomes useless as the artifacts it tries to
> avoid are now caused by blend 

The changing part might show some artifacts depending on VO, but that
hardly makes double buffering "useless" as a whole. Also note that first
overlay blend is done before the buffer is made visible, so only
updating the overlay during a frame can cause that, and to avoid it
would require a copy of the whole frame for double buffering (not that I
would forbid anyone from implementing that option, but hardly seems
necessary for a usable implementation).