Okay, the light bulb finally turned on!

I see that the chromakey is something I can set via XvSetPortAttribute().  I
also see what you mean about not directly putting the image and drawing the
data to the window.

The following sequence seems to be working well:

For each video frame:
1.  XFillRectangle() - to fill a pixmap with the chromakey
2.  XDraw...() to put my data into the pixmap
3.  XCopyArea() to copy the pixmap onto the window
4.  XvShmPutImage() to place the video "under" the drawn data on the window.

The overlays may update a split second before the associated video, and I
get a flicker when there is a real exposure event, but I think that is
acceptable.

Thank you both very much for the help!

- Steve

>
>    Most drivers implement XvShmPutImage as a video overlay.  That
> means it's not "draw" into the window.  It was not the intention
> that one should be able to render XvShmPutImage into a window along
> with normal Xlib rendering, subsequently, that type of thing is not
> supported in the general case.  Some drivers offer non-overlay Xv
> PutImage adaptors that will have the behavior you desire.   Check
> the output of "xvinfo".  Usually PutImage adaptors that do not
> support the XV_COLORKEY port attribute are such adaptors.
>
>                       Mark.
>
> On Wed, 12 Nov 2003, Steve Thrash wrote:
>
> > I am using XvShmPutImage to draw video via a YUV overlay into a window.
> > Then I am using XDraw commands to draw "overlays" directly to the window
> > (lines, arcs, text, etc.).
> >
> > When I do this the video image appears correctly, but the
> overlays do not
> > update properly.  Each time the overlays move, the old XDraw
> data remains
> > along with the new, until I do something to force an exposure on the
> > drawable - such as drag a window over it.  Then the window is
> redrawn with
> > only the new XDraw data drawn over the video image ("new"
> meaning from XDraw
> > calls made since the last XvShmPutImage call) which is what I wanted.  I
> > don't seem to be able to force the XServer to re-expose the window via
> > software, or I would find that an acceptable workaround.  Is
> there something
> > I am not understanding?
> >
> > I have seen this same behavior both on a Matrox G550 and an
> nVidia Quadro 4
> > card, so I don't believe it has anything to do with the
> particular graphics
> > card drivers.
> >
> > Thanks in advance,
> >    Steve Thrash
> >
>
> _______________________________________________
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
>

_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Reply via email to