Re: [xine-devel] DRAWABLE_CHANGED

[Barr <xb...@ni...>]

Hi,

Indeed, looking at the sources it looks like Xine is using the new drawable=
=20
right after the call is made... Maybe it's something on the Qt side. I'll=20
report here when I got this problem solved.

Thanks,
barr

Le Friday 05 March 2004 14:09, Miguel Freitas a =C3=A9crit=C2=A0:
> On Thu, 2004-03-04 at 19:19, Barr wrote:
> > What's happening, I believe, is that a frame is being hold by the
> > XLockDisplay() just before it's rendered and that it's rendered just
> > after I unlock the display, but, still using the old handle. I got
> > exactly one complain from X (major 4) when doing this after what it all
> > becomes fine again.
>
> That hypothesis sound strange. Checking
> xine-lib/src/video_out/video_out_xv.c, function xv_display_frame(),
> this->drawable is only used with the display locked.
> XINE_GUI_SEND_DRAWABLE_CHANGED changes this->drawable immediately
> (inside your locked display context), so the new handle would be used as
> soon as you call XUnlockDisplay.
>
> Maybe you should add some printf's to video_out_xv.c to make sure what
> the problem is?
>
> Btw, i think frontends have usually 2 handles (one for fullscreen and
> another for window). So they just map/unmap and set the drawable
> accordingly. Can you this approach?
>
> regards,
>
> Miguel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> xine-devel mailing list
> xin...@li...
> https://lists.sourceforge.net/lists/listinfo/xine-devel