RE: XvShmPutImage with XDraw commands
The flicker-free solution would be to disable the XV_AUTOPAINT_COLORKEY attribute. That prevents the driver from painting the key, leaving it entirely your responsibility. Then you can do something like draw your scene (key+graphics) into the window yourself, or if you're not changing the graphics frequently, draw it into a pixmap and set that pixmap as the window background. In that case you update the graphics by redrawing the pixmap, resetting it as the window background and then calling XClearWindow. If you do something like that, you never need to handle expose events. The server automatically paints the window background on expose events. Mark. You are right (of course) that did make for a flicker free solution. I'll have to think about some of the other implications you said - although our background will be updating at about 30 FPS - there could be good implication during freeze frame or other times. On a related note, what does the double buffering option give you? Does it allow you to call XvShmPutImage before the old image has finished drawing to the drawable? It looks like the server handles it all automatically. Also - is XvMC the right solution if I want to blend two images to an arbitrary percentage tranparency at 30 FPS using the graphics hardware? Thanks again, Steve ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XvShmPutImage with XDraw commands
On Thu, 13 Nov 2003 08:51:25 -0500, Steve Thrash wrote: Also - is XvMC the right solution if I want to blend two images to an arbitrary percentage tranparency at 30 FPS using the graphics hardware? Unless I have missed a staff meeting somewhere, XvMC is specifically designed to allow hardware acceleration of MPEG motion compensation vectors. It is VERY specific to the MPEG protocol, and is likely of no use in any other context. The xrender extension can do alpha blending, although driver support is still lacking. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XvShmPutImage with XDraw commands
--Original Message Text---
From: Steve Thrash
Date: Wed, 12 Nov 2003 13:09:01 -0500
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.
I'm not sure why this should be a surprise to you. When you use an overlay, the on-screen window gets solid filled with a chromakey color. If you draw something over the top of the chromakey fill, those somethings will be visible until either you erase them, by restoring the chromakey, or you force an expose event, which tells xvideo to fill with the chromakey again.
This is working by design. If the chromakey refilled with every overlay update, it would be impossible to draw anything over a running movie.
--
-TimRoberts,[EMAIL PROTECTED]
Providenza&Boekelheide,Inc.
RE: XvShmPutImage with XDraw commands
Sorry,
I'mkind of new to Xv.
That
makes perfect sense. Is there a way to force the expose event at the
server without actually changing what is viewed (mapping/unmapping, moving,
etc)? I tried XSendEvent, but that didn't seem to
work.
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. I'm not sure why
this should be a surprise to you. When you use an overlay, the on-screen
window gets solid filled with a chromakey color. If you draw something over
the top of the chromakey fill, those somethings will be visible until either
you erase them, by restoring the chromakey, or you force an expose event,
which tells xvideo to fill with the chromakey again.This is working by
design. If the chromakey refilled with every overlay update, it would be
impossible to draw anything over a running movie.---TimRoberts,[EMAIL PROTECTED]ProvidenzaBoekelheide,Inc.
RE: XvShmPutImage with XDraw commands
One
more question - how can you tell what the chromakey value is? Do I need to
use XGetImage or is there a better way?
Sorry, I'mkind of new to Xv.
That
makes perfect sense. Is there a way to force the expose event at the
server without actually changing what is viewed (mapping/unmapping, moving,
etc)? I tried XSendEvent, but that didn't seem to
work.
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. I'm not sure why this should be a surprise to
you. When you use an overlay, the on-screen window gets solid filled with a
chromakey color. If you draw something over the top of the chromakey fill,
those somethings will be visible until either you erase them, by restoring
the chromakey, or you force an expose event, which tells xvideo to fill with
the chromakey again.This is working by design. If the chromakey
refilled with every overlay update, it would be impossible to draw anything
over a running movie.---TimRoberts,[EMAIL PROTECTED]ProvidenzaBoekelheide,Inc.
Re: XvShmPutImage with XDraw commands
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
RE: XvShmPutImage with XDraw commands
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
RE: XvShmPutImage with XDraw commands
On Wed, 12 Nov 2003, Steve Thrash wrote: 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! The flicker-free solution would be to disable the XV_AUTOPAINT_COLORKEY attribute. That prevents the driver from painting the key, leaving it entirely your responsibility. Then you can do something like draw your scene (key+graphics) into the window yourself, or if you're not changing the graphics frequently, draw it into a pixmap and set that pixmap as the window background. In that case you update the graphics by redrawing the pixmap, resetting it as the window background and then calling XClearWindow. If you do something like that, you never need to handle expose events. The server automatically paints the window background on expose events. Mark. - 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 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
