GNOME Bugzilla – Bug 302419
fullscreen window background doesn't repaint
Last modified: 2007-01-05 11:56:30 UTC
After the fullscreen controls hide, they still appear on the fullscreen window. It is as if the fullscreen window never repaints the area where there is no video. Switching workspaces with a keybinding will clear the fullscreen window. This is an old bug that was fixed for a brief time. It's back baby!
xine-lib or GStreamer backend? If it's the xine-lib backend, could you try setting the "video.driver" to be xv instead of auto?
xine. Changing the setting doesn't seem to help.
John, still the case?
For me it is. I am running CVS xine-lib and whatever version of totem shipped with gnome 2.12. I think it is specific to video card driver on an i830 laptop it works fine but on my nvidia *the evil one* driver totems window doesn't refresh. I had some patch for xine-lib that brute forced repainting of the entire window, but I lost it a while ago. Using xine-ui or mplayer there isn't a problem.
Could you double-check that Totem is using the Xv module (with "totem --debug"), and tell which version of xine-lib you're using?
Relevant output: video_out_xv: using Xv port 270 from adaptor NV17 Video Texture for hardware col orspace conversion and scaling. video_out_xv: this adaptor supports the yuy2 format. video_out_xv: this adaptor supports the yv12 format. x11osd: unscaled overlay created (XShape mode). video_out: thread created xine-lib CVS aka 1.1.1
.
*** Bug 322334 has been marked as a duplicate of this bug. ***
I'm seeing this too using the Xv module, Totem 1.2.1 and xine-lib 1.0.1 on Ubuntu Breezy.
I am seeing this too with the xv module, totem 1.2.0, libxine1c2_1.0.1-1ubuntu10.2_i386, ubuntu breezy. Here is the output of totem --debug: video_out_xv: using Xv port 270 from adaptor NV17 Video Texture for hardware colorspace conversion and scaling. video_out_xv: this adaptor supports the yuy2 format. video_out_xv: this adaptor supports the yv12 format. x11osd: unscaled overlay created (XShape mode). video_out: thread created audio_alsa_out : supported modes are 8bit 16bit 24bit 32bit mono stereo (4-channel not enabled in xine config) (4.1-channel not enabled in xine config) (5-channel not enabled in xine config) (5.1-channel not enabled in xine config) (a/52 and DTS pass-through not enabled in xine config) audio_out: thread created xine_stream_new video_out_xv: VO_PROP_INTERLACED(0)
My totem --debug output is identical to the two already posted here.
Just a remark: the problem does not only affect fullscreen mode. See bug 322334 for a screenshot.
Good news. The problem does not occur in ubuntu dapper, with the gstreamer backend. However, it still occurs with the xine backend. Details: gstreamer-0.10, totem-1.3.0-0ubuntu4, totem-gstreamer-1.3.0-0ubuntu4, totem-xine-1.3.0-0ubuntu4.
This was mentioned in https://launchpad.net/distros/ubuntu/+source/totem/+bug/41117 as well.
*** Bug 340396 has been marked as a duplicate of this bug. ***
This happens both in fullscreen and out of full screne for me, as long as theres a part visible not part of the window xine backend, ubuntu dapper
I never mentioned that but it has always been the case.
*** Bug 341598 has been marked as a duplicate of this bug. ***
Ehm... So is this going to be fixed? The xine backend is unuseable this way (and gstreamer is always unuseable).
(In reply to comment #19) > Ehm... So is this going to be fixed? The xine backend is unuseable this way > (and gstreamer is always unuseable). If only I had decent explanations on how to reproduce the problem. Instead, only thing I can say is "works for me". That's using Totem 1.5.4 and xine-lib 1.1.2 (CVS HEAD actually).
I'm also using Totem 1.5.4 and xine-lib cvs (now I do anyways) and I wish I could somehow not reproduce this problem. Other applications using Xine as a backend don't have this problem (GXine, KMplayer, Kaffeine). Changing the display driver for Xine to anything but xv and vidix (or something like that) makes it go away but also reduces image quality and increases cpu usage and what not.
Right, I'll try harder.
Oh and it happens in both Arch Linux and Ubuntu. Ubuntu uses Totem 1.4.1 and Xine 1.1.1.
Theres not really alot to this, but I know that on a standard ubuntu dapper install with totem-xine and any video this happens for me using Xv I haven't tried the others. Would it help if I compiled totem from CVS? (with xine-lib from ubuntu or cvs) I can try that if you like.
Good news! This appears to be fixed in totem 2.16.2 with xine-lib 1.1.2.
I am afraid this is not fixed. In Ubuntu Edgy, I have exactly that configuration (2.16.2 and 1.1.2) but the bug is still there.
dang. It's fixed for me.
It isn't fixed for me either. Tried the 2.16.2 and the 2.17.1. Still running Arch.
Upgrading Totem isn't going to do anything, it's a xine-lib bug...
*** This bug has been marked as a duplicate of 168510 ***