Observed in stock Fedora 8 xorg, confirmed in latest git. The xf86-video-savage driver uses colorkeying for its implementation of XVideo extension. Also, this driver does not support compiz, so I think compositing managers must use xrender in order to implement compositing when using this driver. When there is no compositing manager active, the xv colorkeying works correctly in all applications (tested totem, gst-launch pipe, mplayer). When a compositing manager is enabled (tested with internal metacity compositor), mplayer is not affected, but gstreamer clients (gst-launch and totem) flash the video contents for an instant, and then the video area is covered by garbage composed of old screen bitmaps. Sometimes, dragging the video window makes the video content appear for an instant, but while dragging, the video area repeatedly flashes between the video content and garbage bitmaps. Somentimes, when dropping the video window, the video area remains normal, but other times, it is covered again by screen bitmaps. Tested at 16bpp.
Created attachment 20054 [details] gst-launch xvimagesink, no compositing manager active Screenshot of gst-launch with xvimagesink and no compositing manager. Dark-green square is the normal color key used in my system.
Created attachment 20055 [details] gst-launch xvimagesink, metacity internal compositing manager active This shows gst-launch with xvimagesink and metacity compositing manager active. Here, the colorkeying has been overwritten by a copy of the background image.
This is a driver issue. At the very least, it should use xf86XVFillKeyHelperDrawable() when available instead of xf86XVFillKeyHelper() to make sure the colour key is drawn correctly for composited windows.
(In reply to comment #3) > This is a driver issue. At the very least, it should use > xf86XVFillKeyHelperDrawable() when available instead of xf86XVFillKeyHelper() > to make sure the colour key is drawn correctly for composited windows. > Thanks for the explanation. I will try to whip up a patch tonight. However, a grep on the drivers from current git show that the only user of xf86XVFillKeyHelperDrawable() is xf86-video-ati. Assuming your explanation is correct, then every single driver that implements xvideo via colorkeying is broken in the same way as xf86-video-savage. How come nobody has noticed it?
(In reply to comment #4) > Assuming your explanation is correct, then every single driver that implements > xvideo via colorkeying is broken in the same way as xf86-video-savage. Right. > How come nobody has noticed it? Not sure, I guess most people don't realize there's a way to improve the problem without using textured video.
Created attachment 20115 [details] [review] Patch to conditionally use xf86XVFillKeyHelperDrawable if available This patch implements a conditional test for the xf86XVFillKeyHelperDrawable and uses it if available. This fixes the colorkeying corruption in the cases I could test (gst-launch and totem). Applies against current git.
Suggested patch has been committed to current git.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.