Created attachment 2919 xorg.conf This bug is in Xfce 4.4 (debian stable - lenny) but it is also in Xfce4.6 (debian testing - squeeze). These bars are show in shots in the film where camera moving fast but in static shots the image is normal. It isn't so visible but after strict looking it can be notice. Without compositor the image doesn't have this bug. So reproducing will be: 1. Turn on compositor 2. Check existence of bars in movie 3. Turn off compositor 4. Everything is fine :D
Unlikely I can fix that. Does it show with other players as well? And what about other render (not opengl) based compositors or compositing window managers (xcompmgr, metacity with compositing enabled)?
Xcompmgr give same results as compositor. Compiz doesn't have that problem, everything is smooth. However gxine with compositor give good result, no bars or they appear so slightly that I can't see them. I don't know how can I change this "render based compositors", it is other driver to nvidia card, some other module for Xorg or something else. Can you give me some clue about changing it and rest I will try do.
No, it's the backend used by the compositor, OpenGL (compiz) or XRender (xcompmgr, xfwm4, metacity), this is not something you can change from your config, you would have to rewrite the compositor. If the problem is present with xcompmgr as well, then this is not something specific to xfwm4 compositor.
This is most likely related to tearing due to vsync not working with XRender. Definitely not fixable in Xfwm4.
(In reply to comment #4) > This is most likely related to tearing due to vsync not working with XRender. > Definitely not fixable in Xfwm4. I have the same problem. Disabling the compositor fixes the issue, for mplayer at least. I would like to point out that the same thing (lack of vsync / tearing) happens to regular desktop windows too, regardless of whether compositing is on or off. According to this topic: http://www.phoronix.com/forums/showthread.php?t=25192 vsync should work on recent kernel/driver/mesa combo's, at least for ati cards (I have an r300 based card). Something to note is the following sentence: "Xv windows are redirected to an offscreen buffer so they do not wait for the vline before rendering. The compositing manager copies the content to the visible buffer when it composites the front buffer. As such, it might still tear unless that copy waits for vline as well.". This is taken from a post by 'agd5f' in the above topic. agd5f is the online pseudonym of Alex Deucher, an active X.Org ATI Driver Developer, so that is a reliable source. This indicates that tearing (in video at least) is indeed an issue of the compositing manager, and hence should be fixable in xfwm4. Personally, I think having a tear-free desktop experience is really important, and I would appreciate it if you could look into this some more.
Came here to say: tearing in the compositor (not just in video programs) is the one reason I'm not using XFCE4 right now. Is there any way the compositor can be written to optionally use OpenGL (AIGLX?) instead of XRender? Every XRender-based compositor has been a poor performer with problems like these.
I'd just like to resurrect this thread and add my comment. I too am experiencing this very same issue - tearing in video with fast motion, when Xfce compositing is turned on. No tearing when compositing is turned off. Is there any likelyhood of this being fixed? Cheers, Mike.
The only way to fix vsync tearing is to switch to OpenGL, and I don't think XFCE have the manpower to rewrite the compositor. One, workaround that could be done, is some kind of option that disable compositor effects completely when entering fullscreen applications, like kwin does. That won't fix tearing in the desktop, but at least it could fix tearing while watching videos or playing some games. XFWM4 already unredirects fullscreen windows, but it won't work with videoplayers and some games like Trine2. The result is lower peformance and video tearing. I love XFCE, but the compositor is becoming outdated, and it's time to think of some changes for the future.
(In reply to comment #8) > The only way to fix vsync tearing is to switch to OpenGL, and I don't think > XFCE have the manpower to rewrite the compositor. > > One, workaround that could be done, is some kind of option that disable > compositor effects completely when entering fullscreen applications, like > kwin does. > > That won't fix tearing in the desktop, but at least it could fix tearing > while watching videos or playing some games. > > XFWM4 already unredirects fullscreen windows, but it won't work with > videoplayers and some games like Trine2. The result is lower peformance and > video tearing. > > I love XFCE, but the compositor is becoming outdated, and it's time to think > of some changes for the future. Hi! Why would a change to OpenGL fix the tearing issues? What is the compositor using now? software rendering or what?
(In reply to comment #8) > One, workaround that could be done, is some kind of option that disable > compositor effects completely when entering fullscreen applications, like > kwin does. > [...] xfwm4 had that option since the very beginning, even before KDE had a compositor... wm tweaks -> compositor -> display fullscreen overlay window directly
Also, I assume you are aware of bug 8898 and have tested the patch?
(In reply to comment #10) > (In reply to comment #8) > > One, workaround that could be done, is some kind of option that disable > > compositor effects completely when entering fullscreen applications, like > > kwin does. > > [...] > > xfwm4 had that option since the very beginning, even before KDE had a > compositor... > > wm tweaks -> compositor -> display fullscreen overlay window directly If i turn on the compositor and run a movie in mplayer i get tearing with the option "display fullscreen overlay window directly" activated. Fair enough i have not bothered testing this since 4.8 but this has not changed since then, has it?
And yes, nearly 4 years later, this is still a problem :(
(In reply to Steven Haigh from comment #13) > And yes, nearly 4 years later, this is still a problem :( Time has nothing to do with it, I already reply in comment #1
I agree, however a WONTFIX isn't really a solution over such a long time frame. Compositing and VSYNC is such a basic feature in most DE's. I believe it should really be something that should be addressed - even if it does mean a large project to keep XFCE current and usable.
(In reply to Steven Haigh from comment #15) > I agree, however a WONTFIX isn't really a solution over such a long time > frame. Compositing and VSYNC is such a basic feature in most DE's. > > I believe it should really be something that should be addressed - even if > it does mean a large project to keep XFCE current and usable. hmmm as Olivier says, "Unlikely I can fix that.". I believe the only thing that will fix this problem is Wayland: http://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29 And then you can read: http://wayland.freedesktop.org/faq.html Search for "What is wrong with X?" under the faq. As i recall one of Waylands primary goals is to get rid of these extremely annoying tearing problems... Oh... And see you in another four years then, when Xfce and all other DE:s ported to Wayland. :)
I agree. Something like Wayland would be helpful - however I believe this would be the same amount of re-write to make happen. :)
(In reply to Steven Haigh from comment #15) > I agree, however a WONTFIX isn't really a solution over such a long time > frame. Compositing and VSYNC is such a basic feature in most DE's. > > I believe it should really be something that should be addressed - even if > it does mean a large project to keep XFCE current and usable. Vsync support is there, see comment #11
(In reply to Olivier Fourdan from comment #18) > (In reply to Steven Haigh from comment #15) > > I agree, however a WONTFIX isn't really a solution over such a long time > > frame. Compositing and VSYNC is such a basic feature in most DE's. > > > > I believe it should really be something that should be addressed - even if > > it does mean a large project to keep XFCE current and usable. > > Vsync support is there, see comment #11 Are you in a bitchy mode or are you just happy to see us? ;) Regarding comment 11;: "Cons: - Only works on videodrivers that use DRI, I've only tested it on the Intel HD 3000, but it should also work on AMD gpus, support for Nvidia could be done using OpenGL, but this is a lot of work." Then again... Nothing here actually mentions Nvidia so you are sort of right. If we shall be serious for a moment i think we can actually close this bug as non fixable. Until Wayland we will probably have to live without a compositor. Which is ok for me.
Well, personally, I'm getting into a land of 'gotchas'... 1) My new laptop has dual GPUs. Trying to get them working together (Steam games etc) requires a compositor. 2) XFCE has problems with VSYNC when the compositor is enabled. This causes more problems with tearing while playing videos etc. As such, I'm in this zone where no matter what I do I have problems. I really do love XFCE - so I'd like to come to a working solution - but so far it has eluded me. My next real idea is to try and use compiz - but that's a whole new world of hurt...
> 2) XFCE has problems with VSYNC when the compositor is enabled. This causes more problems with tearing while playing videos etc. Your new laptop is probably using Intel graphics. There's an open bug for that - bug #10416. In fact, bugs #6371 #7237 #10439 are all caused by the same problem - lack of an OpenGL compositor - but it is a particular issue for Intel graphics because Intel removed the GPU commands to do vsync. See https://bugzilla.xfce.org/show_bug.cgi?id=10416#c2 for some details - quote "future hardware will have even more widespread aggressive power savings that assume a compositor, and worst case scenario, the display engine will only be functional with a pageflipping compositor."
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/37. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev