[MPlayer-dev-eng] [PATCH] vo_kva

[Reimar Döffinger]

On Sun, Mar 08, 2009 at 11:12:13PM +0900, KO Myung-Hun wrote:
> > Anyway it is your decision, I just wanted to point out that the vos that
> > I maintain will specifically try to avoid that behaviour and your vo is
> > probably going to stand out from the others by behaving differently,
> > though that is not necessarily a bad thing.
> 
> But what you missed is that the frame window procedure is subclassed 
> only if fixt23 is enabled.

Ok, but then a different name or at least a comment indicating it only
applies to T23 workarounds would be good so you know what it is there
for without having to have preinit in your head.

> > A disabled window is a window that can not receive any input, on Windows you
> > use EnableWindow(vo_window, 0); to set that state. This is usually what
> > is used to disable buttons (in addition to graying them out) so I'd
> > expect that to exist on OS/2, too - but I don't know.
> 
> I think, it's WinEnableWindow(). But with quick test, a disabled window 
> does not pass any event to other window. Anyway if I find the solution 
> using this approach, I'll submit another patch later.

Just to clarify: on Windows a disabled window simply will not get input
focus, its parent window will instead, so there is no need to pass the
events on, they will be directed to the parent window directly.

> > Whether the click that moves focus/brings a window on top counts as
> > click into the window as well is a matter of OS policy, too (as evident
> > by Linux window-managers allowing to choose this).
> > So I think my point stands, but as said if it is important to you keep
> > it.
> 
> I think, if needed, OS policy can be overrided by user. Many enhancers 
> do this.

Yes, but each application separately and in a slightly different way
overriding OS policy tends to lead to a user-interface mess, that was my
only point.

> > Sure, I am just asking if _only_ redrawing the invalidated area is worth
> > the code or if it wouldn't make sense to just draw the whole Window
> > (i.e. something like
> > hps = WinBeginPaint(hwnd, NULLHANDLE, NULL);
> > WinQueryWindowRect(hwnd, &rcl);
> > WinFillRect(hps, &rcl, CLR_BLACK);
> > WinEndPaint(hps);
> > which is much simpler, though e.g. it might cause flicker).
> 
> First of all, it's very out of my expectation that you allow flickering.

Flickering during resizing or moving another window above, sure. Not
ideal but not that bad either. Also it's not a question of flicker vs.
no flicker but whole window flickering or only redrawn window part
flickering.

> And we should consider colorkey as well. So unless we distinguish movie 
> area and black-bar area, movie is not overlaid correctly.

I missed that you subtract the kva-region. IMO a comment at what it does
like "get redraw region, subtract region handled by kva and redraw the
remaining part" might help understanding.

> > That's probably enough to make it work. Without IPB support it will be
> > hard to test though, you could try
> > mplayer -vo kva -dr -vf format=bgr32
> 
> BTW, '-vf format=bgr32' must be specified ?

Without it nearly all decoders will want MP_IMGTYPE_IBP, and your vo
can't offer those, so without get_image would return VO_FALSE right
away. That's not a very good way to test it, is it :-)

If Diego is fine with the build system stuff I'd say it can be applied, if
before or after you send a patch that adds/includes the comments I
suggested that would be great.