Btw, I'm running the latest Fedora Workstation (version 21).

Sounds like virt-viewer needs to set the _NET_WM_BYPASS_COMPOSITOR hint on its window.

Anaconda suffers from a similar problem, see bug 740359. I wonder if it would make sense for gtk+ to unconditionally set the hint to request composition, and grow an API for apps to explicitly opt out of it (for games, etc.)

That seems to explain the behavior I'm seeing, the background flickers on the full-screen window and then vsync breaks on the secondary monitors.  I'm also seeing strange things like windows passing through the full-screen app in a way that doesn't make sense just like the tooltip issue. 

"Bug 740359 - Background windows sometimes flicker through foreground full-screen apps (like anaconda), when a tooltip disappears "

https://bugzilla.gnome.org/show_bug.cgi?id=740359

I'll try the workaround mentioned in that bug-report. Is there anyway to make that permanent if it works?  Will I have to write a simple extension?

Also I think that a fix published to 3.14.1 exposed this bug because in 3.10 I had no such problems on the same Thinkpad T440p.  Mutter apparently used to force vsync on everything.  If that's the case it would be great to revert that patch temporarily.

"Bug 738271 - Gnome Shell not unredirecting fullscreen games in multi-monitor environments "

https://bugzilla.gnome.org/show_bug.cgi?id=738271

What would be best for now is if Mutter forces vsync and compositing on everything unless the user explicity tells Mutter not to via some config.  Most likely there will only be a few apps, things like games less than 10% of all use-cases, that the user wants to work this way.  But every other app, 90% of the other cases (browsers, remmina, virt-viewer, etc...) the user always wants vsync and compositing even when full-screen.

Here are my current packages/kernel:

mutter.x86_64                           3.14.2-1.fc21 
xorg-x11-drv-intel.x86_64               2.99.916-3.20141117.fc21
mesa-dri-drivers.x86_64                 10.3.3-1.20141110.fc21  
Kernel: 3.17.4-302.fc21.x86_64

> Anaconda suffers from a similar problem, see bug 740359. I wonder if it would
> make sense for gtk+ to unconditionally set the hint to request composition, and
> grow an API for apps to explicitly opt out of it (for games, etc.)

Yes this would probably help enormously.  Right now VSYNC is nearly totally broken on my external monitors using the following Xorg values:

'/etc/X11/xorg.conf'

Option      "AccelMethod"  "sna"
Option      "AccelMethod"  "glamor"

It only functions when using the following AccelMethod and '/etc/environment' workaround:

'/etc/X11/xorg.conf'

Option      "AccelMethod"  "uxa"


'/etc/environment'

CLUTTER_PAINT=disable-clipped-redraws:disable-culling
CLUTTER_VBLANK=True

However this results in choppy performance when moving windows around.

Using any combination of the above configurations when apps are full-screen VSYNC breaks on my external monitors and very strange behavior results.  Windows behind the full screen window will pop-out randomly and it seems like the full-screen surface is not solid.  

This is really ruining my experience of GNOME Shell with Fedora Workstation and it's frustrating.  Running Wayland fixes these problems but it's still unstable and locks up at times so that's not an option in a production environment.

(In reply to comment #3)
> Also I think that a fix published to 3.14.1 exposed this bug because in 3.10 I
> had no such problems on the same Thinkpad T440p.  Mutter apparently used to
> force vsync on everything.  If that's the case it would be great to revert that
> patch temporarily.
> 
> What would be best for now is if Mutter forces vsync and compositing on
> everything unless the user explicity tells Mutter not to via some config.  Most
> likely there will only be a few apps, things like games less than 10% of all
> use-cases, that the user wants to work this way.  But every other app, 90% of
> the other cases (browsers, remmina, virt-viewer, etc...) the user always wants
> vsync and compositing even when full-screen.

Please don't revert the patch. That patch is the only way to make Gnome usable for gaming and for VirtualBox/VMware. Unredirection is necessary for performance reasons. It's the reason why it was created in the first place. Compositing requires overhead and unredirection optimizes it away for fullscreen applications. I get huge input latency issues in games and lag in VirtualBox/VMware due to compositing.

(In reply to comment #2)
> Sounds like virt-viewer needs to set the _NET_WM_BYPASS_COMPOSITOR hint on its
> window.

This is the right way to go in my opinion. Apps should request bypass.

(In reply to comment #5)
> (In reply to comment #3)
> > Also I think that a fix published to 3.14.1 exposed this bug because in 3.10 I
> > had no such problems on the same Thinkpad T440p.  Mutter apparently used to
> > force vsync on everything.  If that's the case it would be great to revert that
> > patch temporarily.
> > 
> > What would be best for now is if Mutter forces vsync and compositing on
> > everything unless the user explicity tells Mutter not to via some config.  Most
> > likely there will only be a few apps, things like games less than 10% of all
> > use-cases, that the user wants to work this way.  But every other app, 90% of
> > the other cases (browsers, remmina, virt-viewer, etc...) the user always wants
> > vsync and compositing even when full-screen.
> 
> Please don't revert the patch. That patch is the only way to make Gnome usable
> for gaming and for VirtualBox/VMware. Unredirection is necessary for
> performance reasons. It's the reason why it was created in the first place.
> Compositing requires overhead and unredirection optimizes it away for
> fullscreen applications. I get huge input latency issues in games and lag in
> VirtualBox/VMware due to compositing.
> 
> (In reply to comment #2)
> > Sounds like virt-viewer needs to set the _NET_WM_BYPASS_COMPOSITOR hint on its
> > window.
> 
> This is the right way to go in my opinion. Apps should request bypass.

Yes, this does seem like the best approach.  This may be a driver bug in Intel having to do with dri3 in Mesa but I will have to test this out.  For more information please see drago01's comment on:

https://bugzilla.gnome.org/show_bug.cgi?id=738271#c52

As per drago01's instructions bug #738271:
https://bugzilla.gnome.org/show_bug.cgi?id=738271#c52

> Sorry for the late response but I usually don't pay much attention to closed
> bugs. On intel we now always do page flips so if you get any tearing in the
> composited environment is a driver bug. 
> 
> There are DRI3 fixes for both mesa and the xserver floating around that you
> could try:
> 
> http://lists.freedesktop.org/archives/mesa-dev/2014-December/thread.html#72074
> 
> and those
> 
> http://lists.x.org/archives/xorg-devel/2014-November/thread.html#44634 (which
> are likely to cause your issue). 

I updated to the following packages:

mesa-dri-drivers.x86_64  10.3.5-1.20141207.fc21 @updates
xorg-x11-server-Xorg.x86_64 1.16.2.901-1.fc21 @updates

[Test A,B]

'/etc/X11/xorg.conf'

Option      "AccelMethod"  "uxa"
Option      "AccelMethod"  "glamor"

I have the following behavior:

[laptop] normal <-- "normal" meaning vsync is working properly
[screen a] normal
[screen b] normal

[laptop] normal   
[screen a] fullscreen app --> tearing, artifacts
[screen b]  tearing, vsync broken

[laptop] normal   
[screen a] fullscreen window closed --> tearing stops after a few seconds
[screen b] normal --> tearing stops after a few seconds

[Test C]

'/etc/X11/xorg.conf'

Option      "AccelMethod"  "sna"

I have the following behavior:

[laptop] normal 
[screen a] tearing, vsync broken
[screen b] tearing, vsync broken

[laptop] normal   
[screen a] fullscreen app --> tearing, artifacts
[screen b] tearing, vsync broken

[laptop] normal   
[screen a] fullscreen window closed --> tearing, vsync broken
[screen b] tearing, vsync broken

So it appears that even with the Xorg and DRI3 "pageflip" fixes applied that under SNA vsync is totally broken on the external monitors.  Tearing also occurs with UXA and Glamor but only after an app has gone full-screen and then after that window is closed vsync returns to normal.  Very strange behavior and I have no clue what could be causing it.

Just to reply to your comment from the other bug "This is looking like a Mutter related bug after-all" uh no.

That conclusion is wrong the mesa build you have tested does not have the patches I pointed you at and if an application (or a compositor) asks the driver "please vsync" and it doesn't its a driver bug. Please file a bug on fdo and/or test the mesa patches (you'd have to rebuild the package with them).

Also which app are you using on "screen a" ?

(In reply to comment #8)
> Just to reply to your comment from the other bug "This is looking like a Mutter
> related bug after-all" uh no.
>
> That conclusion is wrong the mesa build you have tested does not have the
> patches I pointed you at and if an application (or a compositor) asks the
> driver "please vsync" and it doesn't its a driver bug. Please file a bug on fdo
> and/or test the mesa patches (you'd have to rebuild the package with them).

You could be correct but I'm not sure.  It seems that everything was working until I updated from GNOME 3.10 to GNOME 3.14, so my initial hypothesis is that it's due to some change in the way Mutter tells the driver to vsync.  Perhaps that was the "PageFlip" thing.  Though once again I'm not sure and I want to confirm this.

Do you know if the patches are available via Rawhide because I don't have time to rebuild the packages.

> Also which app are you using on "screen a" ?

I'm using either Virt-Manager, Firefox or Remmina the RDP client.

(In reply to comment #49, Jasper St. Pierre)
https://bugzilla.gnome.org/show_bug.cgi?id=738271
> There might still be a bug in GNOME, don't discount it. Do you see this
> behavior in KDE and Unity?

Just tried KDE 4 on Fedora 21 and vsync is working on Intel HD graphics using KWin in 'kde-workspace 4.11.14-3.fc21'.  I tested all possible use-case scenarios and vsync was predictable and stable showing none of the symptoms present in Mutter.  This was tested with the "AccelMethod" "Glamor" method with default Xorg settings and I'll have to test it out with SNA and UXA to determine if Kwin behaves the same way with those other methods.

Does it work any better if you do:

CLUTTER_PAINT=disable-clipped-redraws:disable-culling gnome-shell --replace 

?

AGS, do you have "Suspend desktop effects for fullscreen windows" enabled in Systemsettings -> Desktop Effects -> Advanced tab? Please enable it so we can properly compare.

(In reply to comment #11)
> Does it work any better if you do:
> 
> CLUTTER_PAINT=disable-clipped-redraws:disable-culling gnome-shell --replace 
> 
> ?

Tried that and it forced vsync using all three UXA, SNA and Glamor backends.  However the performance was extremely choppy as if it was dropping frames.  When I full-screened an app the problem returned and the external monitors where no longer under vsync.

(In reply to comment #12)
> AGS, do you have "Suspend desktop effects for fullscreen windows" enabled in
> Systemsettings -> Desktop Effects -> Advanced tab? Please enable it so we can
> properly compare.

Under both KDE and Cinnamon I get normal behavior when I set this using both Remmina and Virt-Viewer in full-screen on either monitor. I don't see any vsync issues that would indicate a driver issue here.

Has Mutter changed it's vsync method between 3.10 and 3.14?

(In reply to comment #13)
> (In reply to comment #11)
> > Does it work any better if you do:
> > 
> > CLUTTER_PAINT=disable-clipped-redraws:disable-culling gnome-shell --replace 
> > 
> > ?
> 
> Tried that and it forced vsync using all three UXA, SNA and Glamor backends. 
> However the performance was extremely choppy as if it was dropping frames. 
> When I full-screened an app the problem returned and the external monitors
> where no longer under vsync.

That's expected to be slower because it means that we'd always redraw everything.

(In reply to comment #14)
> (In reply to comment #12)
> > AGS, do you have "Suspend desktop effects for fullscreen windows" enabled in
> > Systemsettings -> Desktop Effects -> Advanced tab? Please enable it so we can
> > properly compare.
> 
> Under both KDE and Cinnamon I get normal behavior when I set this using both
> Remmina and Virt-Viewer in full-screen on either monitor. I don't see any vsync
> issues that would indicate a driver issue here.

They don't do the same thing. KDE does disable compositing completly and not just unredirect a single window. And cinamon probably does not have the multiscreen unredirect fix. Does disabling unredirection fix the problem for you? i.e 

1. Alt-F2
2. Type "lg" and press Enter
3. Type "Meta.disable_unredirect_for_screen(global.screen)" and press Enter
4. Try to reproduce

> Has Mutter changed it's vsync method between 3.10 and 3.14?

No, there aren't different "vsync methods" to choose from to begin with.

I've done some more testing and managed to reproduce this bug on my system using two VirtualBox instances. This is using the Nvidia proprietary driver btw.

Setup:

Monitor A (primary, right): VirtualBox VM 1 in fullscreen mode
Monitor B (secondary, left): VirtualBox VM 2 in windowed mode

VM 2 has vsync issues which is observable by repeatedly dragging any window around. Vsync issues goes away when VM 1 is set to windowed.

Also curiously, when VM 1 is in fullscreen and loses focus to another window, say the window of VM 2, mouse clicks back on VM 1 actually go THROUGH it and affect whatever is behind it. When I was testing, it actually brought up a window that was behind VM 1. Seems like the ordering of which window is on top is getting confused when unredirection is triggered, not sure if its relevant to this bug though.

Meta.disable_unredirect_for_screen(global.screen) seems to prevent all of this, but with the downside of disabling unredirection :(

(In reply to comment #16)

> VM 2 has vsync issues which is observable by repeatedly dragging any window
> around. Vsync issues goes away when VM 1 is set to windowed.

Actually, its not just the contents of VM 2 that have vsync issues, it's the entire screen. I dragged a regular window around in Monitor B and it also seemed to have vsync issues. I don't think compositing is being disabled for Monitor B, so why is it having vsync issues?

AGS one more thing can you try:

LIBGL_DISABLE_DRI3=1 gnome-shell --replace and try to reproduce once more?

This (In reply to comment #18)
> AGS one more thing can you try:
> 
> LIBGL_DISABLE_DRI3=1 gnome-shell --replace and try to reproduce once more?

This crashes GNOME Shell and pushes me back to the login screen.

Using the workaround:

> 1. Alt-F2
> 2. Type "lg" and press Enter
> 3. Type "Meta.disable_unredirect_for_screen(global.screen)" and press Enter
> 4. Try to reproduce

Seems to mitigate the problem when using Glamor as the GLX backend when I used both Virt-Manager and Remmina RDP in full-screen.  I created a small extension that loads this at session start as a temporary workaround. I need to more thoroughly test though before I can 100% confirm.

Will need Benjamin Xiao to confirm this works on his machine too.

In comment 16, I already said that the workaround works, but that's because it completely disables unredirection so it doesn't trigger the bug.

Is this somehow related to this bug?

nouveau and nvidia drivers with gnome also has this issue, please see:


https://www.youtube.com/watch?v=CkHJ8R8V31Y

or should I file a separate bug for nouveau/nvidia issue with gnome tearing and vsync issues?

(In reply to drago01 from comment #15)
[...]
> They don't do the same thing. KDE does disable compositing completly and not
> just unredirect a single window. And cinamon probably does not have the
> multiscreen unredirect fix. Does disabling unredirection fix the problem for
> you? i.e 
> 
> 1. Alt-F2
> 2. Type "lg" and press Enter
> 3. Type "Meta.disable_unredirect_for_screen(global.screen)" and press Enter
> 4. Try to reproduce
> 
> > Has Mutter changed it's vsync method between 3.10 and 3.14?
> 
> No, there aren't different "vsync methods" to choose from to begin with.

I only wanted to confirm this workaround finally solves lots of tearing issues I was seeing playing movies with any player (I am now using mpv) on secondary screen (TV) even both, laptop and TV, having the same refresh rate.

In my case I am using kernel-4.0.5, Gnome 3.16, Intel driver 2.99.917 and mesa 10.3.7

If I can help with any testing or more information or anything, please let me know

Thanks a lot

Looks like Cinnamon is currently disabling it because of the same problems and that is probably the cause you weren't suffering this issue with it:
https://github.com/linuxmint/muffin/commit/d2c9701b673eea9028f4167523ba9775987928ed

As this also looks to cause other bugs like bug 738719 (I haven't yet tried that suggested extension to switch this on/off as Cinnamon allows)

(In reply to Pacho Ramos from comment #23)
> (In reply to drago01 from comment #15)
> [...]
> > They don't do the same thing. KDE does disable compositing completly and not
> > just unredirect a single window. And cinamon probably does not have the
> > multiscreen unredirect fix. Does disabling unredirection fix the problem for
> > you? i.e 
> > 
> > 1. Alt-F2
> > 2. Type "lg" and press Enter
> > 3. Type "Meta.disable_unredirect_for_screen(global.screen)" and press Enter
> > 4. Try to reproduce
> > 
> > > Has Mutter changed it's vsync method between 3.10 and 3.14?
> > 
> > No, there aren't different "vsync methods" to choose from to begin with.
> 
> I only wanted to confirm this workaround finally solves lots of tearing
> issues I was seeing playing movies with any player (I am now using mpv) on
> secondary screen (TV) even both, laptop and TV, having the same refresh rate.
> 
> In my case I am using kernel-4.0.5, Gnome 3.16, Intel driver 2.99.917 and
> mesa 10.3.7
> 
> If I can help with any testing or more information or anything, please let
> me know
> 
> Thanks a lot

Looks like this steps work but *only* if I have previously run:
CLUTTER_PAINT=disable-clipped-redraws:disable-culling gnome-shell --replace

(In reply to Pacho Ramos from comment #24)
> Looks like Cinnamon is currently disabling it because of the same problems
> and that is probably the cause you weren't suffering this issue with it:
> https://github.com/linuxmint/muffin/commit/
> d2c9701b673eea9028f4167523ba9775987928ed
> 
> As this also looks to cause other bugs like bug 738719 (I haven't yet tried
> that suggested extension to switch this on/off as Cinnamon allows)

As looks like this is hard to fix... could this option be added to not need to follow all the steps to workaround the issue? (It's a headache to repeat all the steps each time gnome-shell is restarted and I need to use my HDMI connection)

Thanks

Maybe something like done in muffin/cinnamon:
https://github.com/linuxmint/muffin/commit/d2c9701b673eea9028f4167523ba9775987928ed

Or, if you think it's a bug in intel driver or the relevant video player (maybe they should set NET_WM_BYPASS_COMPOSITOR properly when playing videos in fullscreen mode to prevent tearing), please let me know to report it to the proper place.

It's really surprising to me to keep this broken for years in gnome and ignore the problem forever, I don't think it's so strange to try to play videos on a external TV/screen using gnome desktop, and now we are needing to follow steps on comment #25 every time gnome-shell is restarted :|

I think we should be able, like in Cinnamon, Compiz, KDE, etc..., to choose if we want to enable the unredirected feature or not. So everybody can choose the best behavior for him.

To go further, when the unredirected feature is enabled we should be able, like in compiz, to choose the windows that should not be unredirected:

https://lh3.googleusercontent.com/-aQQ95EPCnT8/UNs5M_e7c4I/AAAAAAAALus/SW-RRCq5_-A/w506-h324/Unredirect%2BFullscreen%2BWindows%2Bubuntu%2B12.10%2B.png

This way every possible behavior are handled and every users are happy!

A use case for me is to always enable "unredirected windows" since I don't play games but I watch some movies with MPV and some online videos with Firefox. Unredirected windows allow me to have have smooth playback in MPV and in Firefox with HTML5 videos. Everything works perfectly with theses exemples (smooth, no tearing) but there is one case where I want/need to turn off "unredirected windows". It's when I play Flash videos in Firefox. There is some tearing but it's fixed if I manually disable "unredirected windows". 

For exemple, if the option to disable some undirected windows was implemented I will disable "plugin-container" (flash player in Firefox) and I will never have tearing again.

(In reply to jeremy9856 from comment #30)
> For exemple, if the option to disable some undirected windows was
> implemented I will disable "plugin-container" (flash player in Firefox)

The correct fix for this is *not* an option in mutter, but Firefox setting the _NET_WM_BYPASS_COMPOSITOR[0] hint on the plugin-container window.

[0] http://cgit.freedesktop.org/xdg/xdg-specs/tree/wm-spec/wm-spec.xml#n1579

Ok maybe for this particular case, I will check on the Firefox side.

I agree that in a perfect world every applications follows the same rules and set the right setting for your config but in the real world it's not that simple and it will never happen. Maybe for my case if I use a different hardware the feature tou proposed isn't needed at all. There is way too much different use case to always automatically have the right setting.

As I said and like others compositors do, a way to choose manually how the compositor work is really important. Don't you see this ?

(In reply to Florian Müllner from comment #31)
> (In reply to jeremy9856 from comment #30)
> > For exemple, if the option to disable some undirected windows was
> > implemented I will disable "plugin-container" (flash player in Firefox)
> 
> The correct fix for this is *not* an option in mutter, but Firefox setting
> the _NET_WM_BYPASS_COMPOSITOR[0] hint on the plugin-container window.
> 
> [0] http://cgit.freedesktop.org/xdg/xdg-specs/tree/wm-spec/wm-spec.xml#n1579

Firefox is a native Windows app that has been ported to Mac/Linux.  Of the two Mac get's much better support as Linux is only a tertiary platform. This is the case for the vast majority of desktop apps today. Given this reality it's unrealistic to assume every single app will adhere to GNOME standards. That's why you need system wide overrides for apps that don't behave according to specifications.

In most desktop/workstation use-cases tearing on 2D surfaces is very unpleasant.  Games are the only apps that benefit from having vsync turned off in the compositor, especially when full-screen.  Games however for the most part use hardware based vsync usually handled directly by their engines as well as with Nvidia's Gsync and AMD's Freesync. 

Mutter should force vsync on all apps on all screens and have application profiles for use with games.  Gamers are already used to configuring such profiles in their GPU settings panels. This would be the easiest way to ensure that gamers can get undirect fullscreen windows if they want when running their games.

If the above is asking too much there should at least be a system-wide switch to force vsync on everything if that is desired though that should be default anyways.

(In reply to AGS from comment #33) 
> If the above is asking too much there should at least be a system-wide
> switch to force vsync on everything if that is desired though that should be
> default anyways.
I don't think I "ask" too much. Like you I think mutter need a switch to enable / disable the vsync. The only thing that I think is useful in addition is to be able to specify some windows to bypass the unredirect option (Kwin and Compiz have this option).

(In reply to AGS from comment #33) 
> Mutter should force vsync on all apps on all screens and have application
> profiles for use with games.  Gamers are already used to configuring such
> profiles in their GPU settings panels. This would be the easiest way to
> ensure that gamers can get undirect fullscreen windows if they want when
> running their games.
> 
> If the above is asking too much there should at least be a system-wide
> switch to force vsync on everything if that is desired though that should be
> default anyways.

I think forcing vsync on everything is too brute force of a method. You're working around an issue that the application or driver layer needs to solve. Plus taking vsync out of an application's hands creates a lot of other problems as well, such as input latency and motion jitteryness as seen with Oculus Rift games.

Also your proposal to have application profiles for games can't cover all potential use cases and you're shifting responsibility to the Gnome devs who can't possibly keep track of every single game that releases.

> Gamers are already used to configuring such profiles in their GPU settings panels.

Actually, most gamers are just using the in-game vsync option, which provides way more performance than driver level vsync.

(In reply to Benjamin Xiao from comment #35)
> (In reply to AGS from comment #33) 
> > Mutter should force vsync on all apps on all screens and have application
> > profiles for use with games.  Gamers are already used to configuring such
> > profiles in their GPU settings panels. This would be the easiest way to
> > ensure that gamers can get undirect fullscreen windows if they want when
> > running their games.
> > 
> > If the above is asking too much there should at least be a system-wide
> > switch to force vsync on everything if that is desired though that should be
> > default anyways.
> 
> I think forcing vsync on everything is too brute force of a method. You're
> working around an issue that the application or driver layer needs to solve.
> Plus taking vsync out of an application's hands creates a lot of other
> problems as well, such as input latency and motion jitteryness as seen with
> Oculus Rift games.
> 
> Also your proposal to have application profiles for games can't cover all
> potential use cases and you're shifting responsibility to the Gnome devs who
> can't possibly keep track of every single game that releases.
> 
> > Gamers are already used to configuring such profiles in their GPU settings panels.
> 
> Actually, most gamers are just using the in-game vsync option, which
> provides way more performance than driver level vsync.

How many GNOME users are playing games with Oculus Rift when it's SDK's [1] have only been officially released and supported for Windows?  AFAIK Linux and Mac support was put on hold indefinitely [2]. You can no longer consider this a valid use-case.

Also, it's not "too brute force", it's having a desktop environment that works consistently whether you use one monitor or many with any app. GNOME devs wouldn't have to hardcode application profiles for games but create a configuration file or something accessible via dconf that Mutter would read before launching an app fullscreen.

Gamers are used to tweaking their games and systems like this, see 'Appendix J. Application Profiles' of the Nvidia UNIX drivers README [3].


[1] https://developer.oculus.com/downloads/
[2] http://thenextweb.com/dd/2015/05/15/oculus-rift-drops-mac-and-linux-targets-windows-pcs-only/
[3] http://us.download.nvidia.com/XFree86/Linux-x86_64/352.55/README/profiles.html

> How many GNOME users are playing games with Oculus Rift when it's SDK's [1] have only been officially released and supported for Windows?  AFAIK Linux and Mac support was put on hold indefinitely [2]. You can no longer consider this a valid use-case.

Motion jitter with forced vsync isn't specific to Oculus Rift but to all 3D games in general. I was merely pointing out Oculus Rift because motion jitter in this case actually induces vomiting. Also, just because Oculus put Linux and Mac dev on hold doesn't mean it won't pick back up again, in which case you'll need a non-hack solution to properly fix this situation. In addition, there are other headsets like the HTC Vive that plan to have Linux support on day 1. This is an extremely valid use case, especially when you have major companies like Valve starting to push Linux gaming as a viable option. Performance DOES matter.

> Also, it's not "too brute force", it's having a desktop environment that works consistently whether you use one monitor or many with any app.

It is brute force because you're not fixing the problem at its source but instead relying on a blanket method of forcing vsync on everyone. The problem should be solved at the driver level, GUI toolkit level or in the way applications draw to the screen. I don't have a problem with the implementation of some dconf value that can force compositing. What I do have a problem with is your belief that this value should be on by default. It completely defeats the purpose of developing unredirection in the first place.

> Gamers are used to tweaking their games and systems like this, see 'Appendix J. Application Profiles' of the Nvidia UNIX drivers README [3].

You seriously expect gamers to make those complicated configuration setups? I've been gaming on Linux for the past year and I haven't had to touch a single one of those profiles. It's ridiculous that you seem to want to put the onus of configuration on gamers when game developers have actually spent the time to get proper vsync in their applications. Gamers shouldn't have to pay for the mistakes of applications who aren't drawing to the screen properly in the first place.

Also I just tested Remmina and Virt-Manager in Fedora 23 running on a Lenovo X1 Carbon which has a Haswell chip. I can no longer reproduce this issue on my triple display setup.

Please test Fedora 23 using SNA with the TearFree option.

Now the rest of users are forced to follow even more complicated steps to simply play a video on a TV or external screen :/ (well, even moving a gnome-terminal window across the screen will also show a noticeable tearing :S). And this is with mpv, mplayer... even totem. Well, maybe I should try to report to all this apps to use the _NET_WM_BYPASS_COMPOSITOR hint

I have no problem with that option being enabled or not by default... but I would prefer to be able to get it enabled/disabled from gnome-control-center instead of needing to teach all the people about how to mess with dconf value :|

Thanks

> (well, even moving a gnome-terminal window across the screen will also show a noticeable tearing :S).

Then your vsync problems are unrelated to this bug. This bug is talking about vsync issues during unredirect fullscreen when compositing is disabled. You seem to be experiencing tearing even during compositing.

Please enable the TearFree option with SNA acceleration.

(In reply to Benjamin Xiao from comment #39)
> > (well, even moving a gnome-terminal window across the screen will also show a noticeable tearing :S).
> 
> Then your vsync problems are unrelated to this bug. This bug is talking
> about vsync issues during unredirect fullscreen when compositing is
> disabled. You seem to be experiencing tearing even during compositing.
> 
> Please enable the TearFree option with SNA acceleration.

No please don't suggest that. TearFree + compositing adds an extra overhead that isn't needed.

If you have tearing in regular desktop enable DRI3 instead. This will enable the buffer_age extension which allows us to do tear free partial screen updates. (And that isn't a gnome issue go complain to your distro / driver vendor for not enabling DRI3 by default).

Last time I checked (few weeks ago) DRI3 wasn't properly supported by intel driver. Also, are you sure the issue is different? In my case I don't get any tearing at all when running, for example, on icewm or blackbox. Neither when restarting gnome-shell with the steps posted in comment #23

Thanks

@drago01, that's good to know! I will try using that

@Pacho, archwiki says you can enable DRI3 https://wiki.archlinux.org/index.php/Intel_graphics#Direct_Rendering_Infrastructure_3_.28DRI3.29

Also yes, you're getting vsync tearing in composited environments, so even if you disabled unredirect you'd be getting tearing. When you did that test where you moved the gnome terminal, was there a fullscreen window on another monitor?

Thanks for the reply :)

Regarding the driver, the reason archwiki shows how to enable DRI3 support is because it has been disabled by upstream on purpose because it's too broken:
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=b6eeb7a1f7efa591504070b606be655e27e6e9c2

For example, Fedora also disabled it because of that:
http://pkgs.fedoraproject.org/cgit/xorg-x11-drv-intel.git/tree/xorg-x11-drv-intel.spec
"* Wed May 20 2015 Adam Jackson <ajax@redhat.com> 2.99.917-9
- Today's git snap
- Don't force the default to DRI3, use upstream's preference
- Fix build failure due to GCC PR65873"

Then... it's a bit tricky I guess to rely on that as it can cause other users :(

Regarding the tearing with gnome-terminal -> I get tearing with gnome-terminal when moving it, but there is *no* fullscreen window on any monitor while doing that test

(In reply to Pacho Ramos from comment #43)
> Then... it's a bit tricky I guess to rely on that as it can cause other
> users :(

Again this is a driver side issue. We *have* to rely on a working driver. Adding comments to this bug won't change that. (btw. the modesetting driver does enable DRI3 by default). 

And probably we should enable it in Fedora again now that xserver 1.18 is out.

> Regarding the tearing with gnome-terminal -> I get tearing with
> gnome-terminal when moving it, but there is *no* fullscreen window on any
> monitor while doing that test

Yes that exactly what buffer_age would fix. If you enable DRI3 (or use a wayland session) you get it.

OK, thanks a lot for the information and sorry for the noise. I will probably wait for us (Gentoo) have xorg-server-1.18 to retry dri3 or, well, try to move to wayland once it's a bit safer from Gnome point of view

Best regards

(In reply to Florian Müllner from comment #31)
> (In reply to jeremy9856 from comment #30)
> > For exemple, if the option to disable some undirected windows was
> > implemented I will disable "plugin-container" (flash player in Firefox)
> 
> The correct fix for this is *not* an option in mutter, but Firefox setting
> the _NET_WM_BYPASS_COMPOSITOR[0] hint on the plugin-container window.
> 
> [0] http://cgit.freedesktop.org/xdg/xdg-specs/tree/wm-spec/wm-spec.xml#n1579
I managed to make the MPV devs to add _NET_WM_BYPASS_COMPOSITOR[0]. Big thanks for them. https://github.com/mpv-player/mpv/commit/516e7d19da137e7b5b8d19c6f0e093823ecdb3a4

I will check for Firefox to add it too.

But what about to add mutter a switch to enable / disable the vsync. And in addition the possibility to specify some windows to bypass the unredirect option like Kwin and Compiz ?

(In reply to Florian Müllner from comment #31)
> The correct fix for this is *not* an option in mutter, but Firefox setting
> the _NET_WM_BYPASS_COMPOSITOR[0] hint on the plugin-container window.
As I said the MPV devs implement this feature but Mutter doesn't seem to use it.
When Mutter switch to unredirect mode there is a little glitch about 3s after the start of the video. This glitch still happen with this feature.

https://github.com/mpv-player/mpv/issues/2502

(In reply to jeremy9856 from comment #47)
> (In reply to Florian Müllner from comment #31)
> > The correct fix for this is *not* an option in mutter, but Firefox setting
> > the _NET_WM_BYPASS_COMPOSITOR[0] hint on the plugin-container window.
> As I said the MPV devs implement this feature but Mutter doesn't seem to use
> it.
> When Mutter switch to unredirect mode there is a little glitch about 3s
> after the start of the video. This glitch still happen with this feature.
> 
> https://github.com/mpv-player/mpv/issues/2502

That mpv patch makes its window request to bypass the compositor by default which means the mpv needs to vsync itself.

If you want the window to be composited (and automatically benefit from the compositor's vsync) you need to use --x11-bypass-compositor=no

We misunderstood, I will try to explain better.
I want to disable the compositing (enable unredirect mode) when I play a video with MPV. That's why I requested MPV devs to add this feature (_NET_WM_BYPASS_COMPOSITOR[0]).

But Mutter doesn't seem to handle this at all. In theory Mutter should switch to unredirect mode instantly when I launch MPV with this new feature but that's not the case. Mutter wait a few seconds before switching to unredirect mode with its built-in fullscreen window detection.

(In reply to jeremy9856 from comment #49)
> But Mutter doesn't seem to handle this at all. In theory Mutter should
> switch to unredirect mode instantly when I launch MPV with this new feature
> but that's not the case. Mutter wait a few seconds before switching to
> unredirect mode with its built-in fullscreen window detection.

Seems like we have a bug retrieving the hint value, see bug 758544.

I'll leave this one open although it's gotten pretty confusing by now. It would be nice if the original reporter could clarify what's wrong.

(In reply to Rui Matos from comment #50)
> (In reply to jeremy9856 from comment #49)
> > But Mutter doesn't seem to handle this at all. In theory Mutter should
> > switch to unredirect mode instantly when I launch MPV with this new feature
> > but that's not the case. Mutter wait a few seconds before switching to
> > unredirect mode with its built-in fullscreen window detection.
> 
> Seems like we have a bug retrieving the hint value, see bug 758544.
> 
> I'll leave this one open although it's gotten pretty confusing by now. It
> would be nice if the original reporter could clarify what's wrong.

It's my understanding that Mutter requires a fullscreen app to tell it to override the "undirect fullscreen" feature when that app goes fullscreen so it can have vsync applied to it.  Most apps don't provide this hint. Unfortunately on multiple monitor setups when one of those monitors has an fullscreen app - that doesn't support the special hinting - this seems to turn off vsync for all monitors breaking entire desktop causing severe horizontal tearing on those other screens. Applying driver overrides like "TearFree" on Intel does not consistently work around this problem.  Users have reported the same behavior when using Nvidia binary drivers.

This doesn't seem to make much sense. Having vsync forced by the compositor by default works for most apps typically used in full-screen mode which are either productivity, web-browsing or video focused. There is one case games, where it's better to have the game use it's own vsync directly with the graphics driver. 

Due to this Mutter should have a vsync fallback where it defaults to vsync the fullscreen app unless the app specifically tells Mutter to undirect it.  In that case it should not affect vsync on any of the other monitors and just turn off vsync for that one monitor.  There should be a way perhaps via DCONF to tell Mutter to undirect that window for other apps if they don't support it yet.

This is not true. The heuristic we have is that there are 100 full-screen damages. That is, they touch the entire window every single frame, for 100 frames in a row.

Most productivity apps would not submit full-screen damages.

Video players and games would be using full-screen damages, but ideally they'd go through a path that lets the application do its own vblank synchronization.

See here:

https://git.gnome.org/browse/mutter/tree/src/compositor/meta-surface-actor-x11.c#n241
https://git.gnome.org/browse/mutter/tree/src/compositor/meta-surface-actor-x11.c#n182

(In reply to Rui Matos from comment #50)
> (In reply to jeremy9856 from comment #49)
> > But Mutter doesn't seem to handle this at all. In theory Mutter should
> > switch to unredirect mode instantly when I launch MPV with this new feature
> > but that's not the case. Mutter wait a few seconds before switching to
> > unredirect mode with its built-in fullscreen window detection.
> 
> Seems like we have a bug retrieving the hint value, see bug 758544.
That explain why _NET_WM_BYPASS_COMPOSITOR[0] doesn't seem to do anything

> I'll leave this one open although it's gotten pretty confusing by now. It
> would be nice if the original reporter could clarify what's wrong.
Again, I think we should be able, like in Cinnamon, Compiz, KDE, etc..., to choose if we want to enable the unredirected feature or not. So everybody can choose the best behavior for him and have control on his computer.

To go further, when the unredirected feature is enabled we should be able, like in compiz, to choose the windows that should not be unredirected:

https://lh3.googleusercontent.com/-aQQ95EPCnT8/UNs5M_e7c4I/AAAAAAAALus/SW-RRCq5_-A/w506-h324/Unredirect%2BFullscreen%2BWindows%2Bubuntu%2B12.10%2B.png

This way every possible behavior are handled, it's flexible and every users are happy!

(In reply to Jasper St. Pierre from comment #52)
> This is not true. The heuristic we have is that there are 100 full-screen
> damages. That is, they touch the entire window every single frame, for 100
> frames in a row.
> 
> Most productivity apps would not submit full-screen damages.
> 
> Video players and games would be using full-screen damages, but ideally
> they'd go through a path that lets the application do its own vblank
> synchronization.
> 
> See here:
> 
> https://git.gnome.org/browse/mutter/tree/src/compositor/meta-surface-actor-
> x11.c#n241
> https://git.gnome.org/browse/mutter/tree/src/compositor/meta-surface-actor-
> x11.c#n182

Interesting, so let's assume that apps such as virt-manager's viewer and others that perform like VNC clients use full-screen damages. Then if I have a virt-manager instance with a virtual machine fullscreen in one monitor, why does that affect vsync in the secondary or third monitors such that dragging non-fullscreen windows would cause tearing in those other monitors?  

That's the core effect of this issue.  

To mitigate that in the past I had to create an extension that would run:

> 1. Alt-F2
> 2. Type "lg" and press Enter
> 3. Type "Meta.disable_unredirect_for_screen(global.screen)" and press Enter

Seems like we're conflating two issues into one thread.

According to the title, this bug should really be about issues with the unredirect fullscreen feature such that, when activated, causes other monitors to be unable to vsync. This isn't about disabling this feature by default or enabling an option in settings, as those are just workarounds for the actual problem.

Steps to reproduce:
1.) Connect two monitors, lets call them Monitor A and Monitor B
2.) Launch Remmina on Monitor A, connect to a RDP or VNC session.
3.) Fullscreen Remmina on Monitor A (such that unredirect fullscreen is triggered)
4.) Launch Gnome Terminal window (or any other non-fullscreen window) on Monitor B
5.) Drag Gnome Terminal around on Monitor B

Actual Results:
Gnome Terminal window will show tearing

Expected Results:
Gnome Terminal window should not show tearing

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.