After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 412950 - [xvimagesink] doesn't refresh with EXA and Composite Extension
[xvimagesink] doesn't refresh with EXA and Composite Extension
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.11
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-02-28 05:32 UTC by Matthias Bläsing
Modified: 2007-03-02 16:59 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description Matthias Bläsing 2007-02-28 05:32:24 UTC
Please describe the problem:
Totem is currently unusable for me, when running a setup with EXA and the composite extension enabled, becaus everytime somethink covers the totem window, the video is hidden in that part. Problem is, that for example gaim causes this effekt for the whole desktop when hiding the gaim window.

Testing with xine and mplayer (both also using the XV extension) don't show this effect.

Steps to reproduce:
1. run a xserver with EXA and Composite Extension
2. gst-launch-0.10 videotestsrc ! xvimagesink
3. move anoterh window over the window of the xvimagesink and move this window away
4. move xvimagesink


Actual results:
on step 3. the part of the xvimagesink window, that was hidden by the other window is not redrawn with the contents of the videotestsource. Moving the window make the contents visible again/completly

Expected results:
in step 3. the xvimageink window should be completly refreshed

Does this happen every time?
yes

Other information:
Comment 1 Jan Schmidt 2007-03-02 12:18:33 UTC
What does remain in the non-refreshed portion of the video window?

My first thought is that this is probably related to the Xv XV_AUTOPAINT_COLORKEY attribute. xine does its own colorkey painting, and I suspect mplayer probably does too, but GStreamer lets the Xserver do it. In that case, it's an EXA/Composite bug for it to not redraw the colorkey properly.

If that's what is going on, I'd expect that the portion of the window that gets obscured ends up containing a picture of the window that lay over it where it is supposed to have the colorkey painted back in.

Matthias, can you confirm or deny this theory?
Comment 2 Matthias Bläsing 2007-03-02 16:04:20 UTC
Actually, when moving the window, that covered the xvimagesink window, I see parts of the window, that lay _under_ it. Switching the XV_AUTOPAINT_COLORKEY off leads to the situation, where the videowindow is not redrawn even when moved.

BUT this is were tests in mergedframebuffer mode of a dualhead setup. I switched to singlehead and ... the window gets refreshed as expected and EXA is noticeably faster. So I think I hit a r300 bug and not an gstreamer one *arg*

Thanks for your help - I will close the bug as NOTABUG and switch over to freedesktop.org and file a bug for the r300 driver. Till then, I'll stay with XAA.
Comment 3 Jan Schmidt 2007-03-02 16:59:09 UTC
Yeah, just switching off the attribute isn't going to help - it means that the application (xvimagesink) is going to be painting color rectangles in the right spots... which of course it doesn't, because it asked the XServer to do it by setting the autopaint attribute.