GNOME Bugzilla – Bug 701801
Tearing workaround leads to window border flicker
Last modified: 2021-07-05 13:53:19 UTC
I'm using the nvidia proprietary driver. Since many versions I use the following workaround to prevent 3D and video tearing on Gnome 3: "CLUTTER_PAINT=disable-clipped-redraws:disable-culling" in /etc/environment This completely eliminates tearing for me but always introduces a new issue: The top part of the window borders (caption) occasionally flicker when using above mentioned workaround. This flicker can also be provoked by rapidly moving the mouse over the close/minimize/maximize buttons back and forth. It happens to me since at least 3.6 or 3.4 no matter if using stock Adwaita theme or a custom one. I use the very same Clutter workaround on Cinnamon to fix the tearing, because its window manager/compositor "Muffin" is a fork of Mutter. HOWEVER, I don't experience any window caption flickering issue on Cinnamon. I experienced this a while back with Gnome 3.6 on Arch Linux x64 and now with Gnome 3.8 on Ubuntu 13.04 x64 using the nvidia proprietary driver - both driver version 304 and 310.
(In reply to comment #0) > I'm using the nvidia proprietary driver. Since many versions I use the > following workaround to prevent 3D and video tearing on Gnome 3: > > "CLUTTER_PAINT=disable-clipped-redraws:disable-culling" in /etc/environment You don't need that to prevent tearing in gnome 3.8. See https://bugzilla.gnome.org/show_bug.cgi?id=669122
Does the nvidia proprietary driver support EXT_buffer_age?
(In reply to comment #2) > Does the nvidia proprietary driver support EXT_buffer_age? Yes starting with version 313.09 "Added support for the GLX_EXT_buffer_age extension." [1], seems like he is still using older drivers (304 and 310) ... Markus you need to update your drivers. 1: http://www.nvidia.com/object/linux-display-amd64-313.09-driver.html
(In reply to comment #3) > Yes starting with version 313.09 "Added support for the GLX_EXT_buffer_age > extension." [1], seems like he is still using older drivers (304 and 310) ... > > Markus you need to update your drivers. > > > 1: http://www.nvidia.com/object/linux-display-amd64-313.09-driver.html Sounds like good news, thanks for the tip! Will the new driver fix tearing for Gnome 3.6 as well or is this exclusive to 3.8?
(In reply to comment #4) > (In reply to comment #3) > > Yes starting with version 313.09 "Added support for the GLX_EXT_buffer_age > > extension." [1], seems like he is still using older drivers (304 and 310) ... > > > > Markus you need to update your drivers. > > > > > > 1: http://www.nvidia.com/object/linux-display-amd64-313.09-driver.html > > Sounds like good news, thanks for the tip! > > Will the new driver fix tearing for Gnome 3.6 as well or is this exclusive to > 3.8? Only for >= 3.8
Okay, now I tried Gnome 3.8 & Nvidia 313.30 on Ubuntu 13.04 without the CLUTTER_PAINT line: 1. Horizontal tearing in videos is gone, as you predicted! Overall smoothness of gnome-shell improved a bit as well. 2. Window caption flicker is STILL happening 3. Whenever playing a 60 FPS video in mplayer I get horizontal/vertical tearing in every application that is above the edges of the mplayer window, exactly at the place where the edges are below. Not happening with the CLUTTER_PAINT line. Since issue no. 2 doesn't seem to be related to the CLUTTER_PAINT line at all, this barely is an improvement considering no. 3 - which is a change for the worse. I might as well keep the /etc/environment line then...
(In reply to comment #6) > Okay, now I tried Gnome 3.8 & Nvidia 313.30 on Ubuntu 13.04 without the > CLUTTER_PAINT line: > > 1. Horizontal tearing in videos is gone, as you predicted! > Overall smoothness of gnome-shell improved a bit as well. > > 2. Window caption flicker is STILL happening Which kind of flicker exactly? Can you record it on a video or something. I see no flicker here at all. > 3. Whenever playing a 60 FPS video in mplayer I get horizontal/vertical tearing > in every application that is above the edges of the mplayer window, exactly at > the place where the edges are below. Not happening with the CLUTTER_PAINT line. This one is very odd. Are you using multiple monitors?
> Which kind of flicker exactly? Can you record it on a video or something. I see > no flicker here at all. It occasionally happens when I move the cursor over the window buttons (close, minimize, maximize) and their texture is switched between hovered and non-hovered. The whole upper part of the window border (area where window caption and window buttons reside on) is entirely white for a split second. I happens rarely under normal usage. I have to quickly move the cursor over the window buttons back and forth to provoke it. Unfortunately it happens too fast to record it on video. I've manipulated a screenshot in GIMP to illustrate how it looks for that split of a second: http://i.imgur.com/kQxy3mN.jpg > This one is very odd. Are you using multiple monitors? No, I'm using a single screen connected via DVI. I've tried using Triple Buffering but the issue persists.
(In reply to comment #8) > > Which kind of flicker exactly? Can you record it on a video or something. I see > > no flicker here at all. > > It occasionally happens when I move the cursor over the window buttons (close, > minimize, maximize) and their texture is switched between hovered and > non-hovered. > The whole upper part of the window border (area where window caption and window > buttons reside on) is entirely white for a split second. > I happens rarely under normal usage. I have to quickly move the cursor over the > window buttons back and forth to provoke it. Unfortunately it happens too fast > to record it on video. I've manipulated a screenshot in GIMP to illustrate how > it looks for that split of a second: http://i.imgur.com/kQxy3mN.jpg > > > > This one is very odd. Are you using multiple monitors? > > No, I'm using a single screen connected via DVI. I've tried using Triple > Buffering but the issue persists. I cannot reproduce any of those. I don't get any tearing at all running the 319.23 driver on 3.8. Nor do I see any flicker of the title bars. I have tested mplayer but not with a 60fps video (because I don't have any right now). Seems to work fine as well. There shouldn't be a difference between your env line and no regarding tearing. When the buffer age extension is present we always swap buffers (which is the reason why your env var helps at all ... it always forces buffer swaps).
Ubuntu has some X server / DRM / GNOME patches. Maybe some of these are causing it? Can you reproduce under Arch Linux with GNOME 3.8?
(In reply to comment #9) > I have tested mplayer but not with a 60fps video (because I don't have any > right now). Seems to work fine as well. It has to be 60fps for the issue to appear. If you want to test it out, here is a 60fps video: http://www.nostro.fr/Download/Distance_2013_New_Year_MEP_60fps.mp4 For better illustration, put a window with drop-down lists (i.e. gnome-tweak-tool) above the mplayer window edges - so that the drop-down element would be divided by one of the mplayer edges below. Now click the drop-down box and hover the entries in the list. The hover highlight will show tearing where the mplayer edge is located below. (In reply to comment #10) > Ubuntu has some X server / DRM / GNOME patches. Maybe some of these are causing > it? Can you reproduce under Arch Linux with GNOME 3.8? I currently don't have an Arch Linux installation on my disks. I'll set one up and report back. Stay tuned.
(In reply to comment #11) > (In reply to comment #9) > > I have tested mplayer but not with a 60fps video (because I don't have any > > right now). Seems to work fine as well. > > It has to be 60fps for the issue to appear. If you want to test it out, here is > a 60fps video: > http://www.nostro.fr/Download/Distance_2013_New_Year_MEP_60fps.mp4 > > For better illustration, put a window with drop-down lists (i.e. > gnome-tweak-tool) above the mplayer window edges - so that the drop-down > element would be divided by one of the mplayer edges below. > Now click the drop-down box and hover the entries in the list. The hover > highlight will show tearing where the mplayer edge is located below. I have tried this now. No tearing either. Tryed VDPAU and XV output. Which exact gnome-shell / mutter version are you using? Did you try 3.8.3? (if the menu "tears" you might be just be hitting the frame sync bug, which got fixed there).
Installed Arch Linux now. Including nvidia 319.23, gnome-shell 3.8.3, mutter 3.8.3 and mplayer2. Both issues are still happening. For better illustration I've dug up my old camera and recorded them: 1. Window flicker: https://dl.dropboxusercontent.com/u/16979896/window_flicker.MOV (my camera's framerate is not so high but you can still notice the caption text flickering) 2. Tearing with mplayer window below other windows: https://dl.dropboxusercontent.com/u/16979896/60fps_tearing.MOV (I'm using the XV output of mplayer2)
(In reply to comment #13) > Installed Arch Linux now. Including nvidia 319.23, gnome-shell 3.8.3, mutter > 3.8.3 and mplayer2. > Both issues are still happening. For better illustration I've dug up my old > camera and recorded them: > > 1. Window flicker: > https://dl.dropboxusercontent.com/u/16979896/window_flicker.MOV > (my camera's framerate is not so high but you can still notice the caption text > flickering) I still cannot make any sense of this one / reproduce it. > 2. Tearing with mplayer window below other windows: > https://dl.dropboxusercontent.com/u/16979896/60fps_tearing.MOV > (I'm using the XV output of mplayer2) OK now I see what you mean and can reproduce it. This is not "tearing" in the classical sense (as in drawing out of the refresh rate) but there seems to be a bug in the dirty region tracking, so we end up using an old buffer without updating it first ... need to investigate.
Out of curiosity, can you reproduce the first issue with raw mutter or metacity?
(In reply to comment #15) > Out of curiosity, can you reproduce the first issue with raw mutter or > metacity? raw mutter: yes, happens too raw metacity: no, doesn't happen and as stated in my original post it doesn't seem to happen with muffin on cinnamon, despite it being a fork of mutter.
Created attachment 248059 [details] [review] WIP: stage-cogl: Call glFinish after glFinish after buffer swap When we reuse the contents of the backbuffer we have to make sure that drawing is done before we can reuse the backbuffer. Do that by calling glFinish after the buffer swap. --- Markus, sorry for the delay got sidetracked with other stuff. Looked at this again now. Can you try this patch? With it I can no longer reproduce it neither with the 60 fps video you linked to neither with glxgears. Of course the patch cannot go in as is because it uses opengl directly from within clutter hence the WIP. Will need to add API to cogl for that.
Created attachment 248060 [details] [review] WIP: stage-cogl: Call glFinish after buffer swap When we reuse the contents of the backbuffer we have to make sure that drawing is done before we can reuse the backbuffer. Do that by calling glFinish after the buffer swap. --- Fix commit message (oh and in case this is not obvious you have to apply the patch to clutter not gnome-shell/mutter).
Created attachment 248064 [details] [review] stage-cogl: Call wait_for_gpu after buffer swap When we reuse the contents of the backbuffer we have to make sure that drawing is done before we can reuse the backbuffer. Do that by calling cogl_onscreen_wait_for_gpu after the buffer swap. This is a non WIP patch, which requires the new cogl API from bug 703327
Created attachment 248068 [details] [review] stage-cogl: Call framebuffer_finish buffer swap when reusing buffers When we reuse the contents of the backbuffer we have to make sure that drawing is done before we can reuse the backbuffer. Do that by calling cogl_framebuffer_finish after the buffer swap. -- Seems that there is already cogl api for that (cogl_framebuffer_finish), so just use that.
Review of attachment 248068 [details] [review]: <bpeel> oh, that is really weird <drago01> bpeel: huh reproduced it with the glFinish thing <bpeel> yeah, it looks more like the dirty region tracking is getting messed up somehow <drago01> bpeel: so maybe this just adds a delay which makes it less likely to happen? <bpeel> yeah, that sounds plausible
So this seems to be a mutter bug after all: <bpeel> i wonder if it's just an ordering issue with the damage events and actually has nothing to do with the buffer age <bpeel> ie, if you get a damage event for the glx window then it would queue a redraw for that small region <bpeel> but then if firefox updates its buffer in the meantime but mutter has already started painting before it gets the damaged event for the firefox window <bpeel> then it will only draw that small square with the new contents <bpeel> so it will look out of place in a frame where the rest of the window still has the old contents <drago01> hmm yeah that makes some sense <bpeel> not sure what to do about it if that is the case <bpeel> that just sounds like a general compositor problem <drago01> well there is the xfence stuff for synchronizing x and gl rendering <drago01> but we don't use it yet <bpeel> well, that's one to add to the list of reasons to use wayland at least :) <drago01> ;)
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.