Fullscreen performance

[JustCauseWhyNot]

When using the fullscreen patch to turn a windowed window into a fullscreen window does it still have the performance of a windowed window or the higher performance of a fullscreen window?

[bakkeby]

I felt this was better placed under discussions rather than issues.

I do not know the exact answer to this question, but I think that it depends on what the actual cause of the performance issues is when running the game in windowed mode.

For all practical purposes you have an X window and a fullscreen X window merely takes up the entire screen and is placed on top of all other windows (including the bar etc.).

From the window manager's side, and the X server's side for that matter, there is no practical difference of running a game in fullscreen compared to running Firefox in fullscreen. As such I would assume that if there are performance issues then they may still be there when running a game in fullscreen in dwm.

It is not an exclusive fullscreen like you may be used to from Windows XP, as in keybindings to switch tags, etc. will still work. That said some games, or the programs managing said games, may change the resolution of the screen when going fullscreen which may potentially improve performance.

If you are using a compositor then that can also have an impact on performance. In picom for example there is an option to stop handling transparency effects and the like when an opaque fullscreen window has been detected.

# Unredirect all windows if a full-screen opaque window is detected,
# to maximize performance for full-screen windows. Known to cause flickering
# when redirecting/unredirecting windows.
#
unredir-if-possible = true;

@vide0hanz has more experience than me in this area and may have something to add.

[bakkeby]

Something else that I haven't been able to confirm is whether the game should also be taken out of fullscreen when losing focus, and be brought back into fullscreen when receiving focus again.

[JustCauseWhyNot]

Interesting. All I know is currently it works flawlessly as long as I let the game load to main menu before moving it around and changing fous.

[vide0hanz]

Something else that I haven't been able to confirm is whether the game should also be taken out of fullscreen when losing focus, and be brought back into fullscreen when receiving focus again.

I believe this is down to personal preference. I often use the losefullscreen patch to force fullscreen applications into windowed mode. Back when I was playing around with manipulating game windows vs Steam client windows I found it very intuitive for games to be brought back into fullscreen when receiving focus. Some people prefer to play certain games in windowed mode, however.

[JustCauseWhyNot]

Something else that I haven't been able to confirm is whether the game should also be taken out of fullscreen when losing focus, and be brought back into fullscreen when receiving focus again.

Could you explain what the difference is from the current behavior of the patch you've provided? Because if it's what I think it is then I think it'd be a good idea too implement that. Because when I change focus too a separate window the game still is receiving input, and that doesn't seem right.

[JustCauseWhyNot]

I can also so I just tried out the losefullscreen patch, and it broke the "alttab" functionality of fnv.

[JustCauseWhyNot]

I've got another question. Does it make sense for the sensitivity of a game to get messed up when changing focus away from it? I'm talking about fnv, and when I switch away from it & back the menu sensitivity is much faster.

[bakkeby]

To be honest I don't think there is a way to prevent that. It should really be up to the program (game) itself to stop taking input after losing focus. It may be that in this particular case the program is not aware that it has lost focus. That said if it works in gnome or most other window managers then dwm does not unmap windows when they are hidden - they are just being moved to a negative x position, so what might help in this context is the https://dwm.suckless.org/patches/windowmap/ patch.

[JustCauseWhyNot]

I appreciate your help. I'll check that patch out. Thank you.

[JustCauseWhyNot]

Ok I've applied windowmap, and it doesn't seem to be fixing the issue of changing window focus moving mouse, and then upon refocusing the mouse has inherited where the mouse position was on other workspace.

[bakkeby]

Well it was worth a shot. The idea was that the program may behave differently when the window is unmapped, but in this case it doesn't appear to have had any positive effect.

[JustCauseWhyNot]

It may for different programs than what I'm trying right now. I agree it was worth a shot thx for letting me know about it.