-
Notifications
You must be signed in to change notification settings - Fork 462
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No direct scanout in fullscreen games with dash-to-dock enabled #2041
Comments
@vanvugt I feel it's your area, it maybe that in some scenarios we should get rid of the dock from the uiGroup... Mhmh. |
Not necessarily my area. The problem here is just that mutter thinks there's a window on top of the fullscreen game which is preventing direct scanout. So it sounds like a simple dash-to-dock bug (or a mutter bug). Perhaps if we fix #1381 then it will be solved? |
@vanvugt I tried to rollback mutter to 43.0-4 and the issue still there. Also I'm sure that previously it was ok and then broken by update of some component (not sure which one, possibly some compatibility regression). |
Also as I told if I login with dash-to-dock disabled and then enable it - everything is fine. And vice versa: if I login with dash-to-dock enabled and then disable it - tearing is still broken. Maybe it will help to investigate. |
Sounds like it could be an (invisible) window/actor leak. Try Alt+F2, |
I didn't find anything... But found some mistake in my original description. Screen tearing don't working under the wayland session at all, probably because it still don't implemented on the GNOME side. I will edit it. |
Yes tearing is actually a bug, not a feature. It's a bug that only exists in X11 and will be fixed in a future Xorg release. So tearing alone should not be a test case. To treat tearing as a feature, you can:
|
Are you sure that it's related to gaming? Because on the gaming side of things lack of tearing breaks everything completely. So, disabled vsync in the game window is completely expected behavior and gaming is not possible without it. And actually it was working like this all the time on the X11 session. And works even now, but without dash-to-dock. So, all of this is a good question, but at least dash-to-dock should not affect this behavior I think (previously it didn't affect). Am I wrong? |
It's complicated. In Xorg open source drivers, tearing is a bug because actually the kernel drivers forbid it. Xorg only tears because of its own inefficient rendering doing a linear buffer copy. That's a bug. In Xorg NVIDIA drivers, tearing is a feature. And you can probably configure it. In Wayland, tearing would be a bug but I don't think you'll ever see it there. It's forbidden by the kernel interfaces we use, at least for open source drivers. For gaming it might be added as a feature later. Disabling vsync and tearing are different things. You can disable vsync without tearing using the mailbox algorithm (in any graphics system, not just Vulkan), which is usually what is used when vsync is disabled in an app.
dash-to-dock should not disable tearing if the system was tearing without it. That's a bug in dash-to-dock or gnome-shell, which is why this issue is open. |
@vanvugt Thank you for such a detailed explanation! I hope this weird stuff will be aligned one day :) |
System
Fedora 37 GNOME 43.5-1, but I also checked on Manjaro with 44
dash-to-dock 83
X11 session
Bug summary
Some time ago I started to notice that games (steam/proton) feels bad (increased input lag, no expected responsiveness). After a lot of experiments I understood that there are no tearing in games even with vsync switched off which breaks the gaming experience almost completely, especially for multiplayer games.
In my next experiments I noticed that there are no such issue with dash-to-dock disabled (need to relogin to see effect).
Also interesting that if I login with dash-to-dock disabled and then enable it - games work as expected (with tearing).
Steps to reproduce
Actual result
No screen tearing, increased input lag
Expected result
Allowed screen tearing
The text was updated successfully, but these errors were encountered: