Re: [PATCH] vo_tdfx_vid.c and vo_xover.c

Hi Arpi,

on Thu, 17 Jul 2003 17:28:58 +0200 you wrote:

> Hi,
> 
> > In my test i get a good cut down on CPU by using this. A 640x272 clip
> > uselly need ~80% of the CPU, need only ~55% with this method.
> > This is according to top so it's not a so good measurment, but still.
> 
> hmm.
Try it for yourself. A better benchmark method miss here :(
Also in video-only mode the timing seems a bit better.
This is very subjective but with soft-sleep it always seems to play
a little bit faster than it should.

> >   xover
> > This is not completly ready. It mostly work (with tdfx_vid) but i must
> > say i have been confused by VOCTRL_RESIZE_DEST. Quoting libvo2.txt :
> >  ---
> > VOCTRL_RESIZE_DEST:
> >     Asks the driver to redefine (move/resize) the display area.
> >     The parameters passed in a int[4] array: x,y,w,h. -1 means
> >     unchanged.
> >  ---
> > So i thought that this would be the position of the window/overlay on
> 
> yes it is.
> but x,y means the position of overlay relative to the window corner,
> not to the screen, so unless you add black bars or do things like
> panscan or zoom, it should be 0,0
> 
> > the screen. But then in x11_helper.c i found :
> >  ---
> >     case VO_EVENT_MOVE:
> >         mp_msg(MSGT_CPLAYER,MSGL_V,"vo-event: moved to %d x
> >         %d\n",x,y);
> > // dont do that, we're moving the window, not the picture inside the
> > window!//        { int tmp[4];
> > //        tmp[2]=tmp[3]=-1; tmp[0]=x; tmp[1]=y;
> > //        vo->control(vo,VOCTRL_RESIZE_DEST,tmp);
> > //        }
> >  ---
> > So it then seemed that this control was intended for something else ?
> > Anyway i uncommented this and used the control for overlay
> > resize/move.
> 
> it's wrong.
> hmm, maybe you're right, the lowlevel overlay drivers need the position
> relative to the screen corner instead of the window corner.
> so your xover should calculate the distance (actually window position)
> and adjust the x,y before passing to the lowlevel overlay driver (vo)
> (where x,y means relative to screen corner, as no windows at all)
> 
> but that should be done by vo_xover, not x11_util!
Ok, i'll do that. It make the implementation a bit more complex but
that make sense.

So if i undestood correctly VOCTRL_RESIZE_DEST define the
position/size of the image in the parent window (wich stuff like xover
translate in screen cords and
VOCTRL_RESIZE_SRC the part of the buffer that should be displayed.
	Albeu
-- 

Everything is controlled by a small evil group
to which, unfortunately, no one we know belongs.