True, it’s just one of the many issues that came to mind while writing this.

My solution to the issue is also full screen borderless combined with resolution scaling.

> just do borderless windowed and pretend true fullscreen doesn't exist.

Hah, good to know I am not the only one.

I do the same, I do wonder however, if there are performance issue at the OS level, from running (on a 4K screen) 4K borderless vs. 4K fullscreen.

Like, the whole giving the application maximum priority would work the same?

Whether there's a performance detriment from borderless-fullscreen vs exclusive-fullscreen depends on how a program presents its frames (and on the OS, of course).

On Windows, under ideal circumstances borderless-fullscreen performs identically to exclusive-fullscreen as Windows will let the program skip the compositor and present its frames more-or-less directly to the display. (Under really ideal circumstances the same applies to bordered non-fullscreen windows.)

If the compositor can't be skipped, borderless-fullscreen can be a bit brutal on performance: on a 4K 160Hz screen I've experienced an additional 40-milliseconds+ of frame-latency purely from borderless-fullscreen being used.

The Special K wiki has some pages that go into more detail about the situation on Windows: https://wiki.special-k.info/SwapChain, https://wiki.special-k.info/Presentation_Model

This is absolutely bonkers.

At least on Xorg it isn't an issue, but to ensure cross-compatibility your solution trumps all. I cannot comment on other platforms.

In Xorg it is definitely an issue. Virtually all games use a borderless window because actual X11 fullscreen is awful: it captures all input events and changes the system's screen resolution to whatever the application is running at.

There is no all-encompassing "actual X11 fullscreen", X11 does not have an API for applications to have control over the entire screen like you'd find in, e.g, DirectX 9 (what most people think of with "real fullscreen" in Windows). What games (and SDL1) ages ago did was to use APIs that changed the video mode and APIs that captured input, both of which are completely separate (they're even from different sources: the video mode API is from an extension, the capture API is from the core protocol) - and then created a borderless window the normal way.

There are three different aspects here, each one can be done differently and all can be (and have been) mixed or ignored:

1. Set the video mode. You can either do that or not and use whatever the desktop is running at. You may want to change the video mode not just for resolution but for using a different refresh rate. Both native games (like, e.g. Quake source ports using SDL2) and Wine still do that (you can disable the modesetting in Wine via the registry so that games only see the desktop resolution as the only available one).

2. Create a fullscreen window. There are two ways to do that: either create a window that bypasses redirection ("redirection" here means that the window manager wont manage it, it has nothing to do with compositing - if a compositor is used - though some compositors also use it as a hint for that) and have it cover the entire desktop area (you may want to use randr to figure out the monitor area for multiple monitors) or alternatively use the fullscreen hint on the window and let the window manager handle this. Note that some window managers may not support this or have bugs with it.

3. Handle input. X11 provides an API to capture mouse and/or keyboard input, though strictly speaking this is not really required and TBH i do not see why games ever did that (i can only think of conflicts with other programs but i'd expect this to be something for the user to deal with). In any case, it is rare for games to do that these days. You can just handle input "normally" like any other program. You can provide a (by default disabled) option if you really want to though as the API for capturing is trivial.

For my last game engine i did #1 (with an option to use whatever the desktop resolution is) and #2 (using the fullscreen flag by default with the redirect flag as an alternative for window managers that had issues with the fullscreen flag) but i didn't bother with #3.

I have no knowledge about such things but…

> The modern strategy is to just do borderless windowed and pretend true fullscreen doesn't exist.

This explains a lot as to why I experienced some interesting inconsistency going full screen in different applications in Windows ;)

In Linux/Wayland, Windows-style fullscreen does not exist and has no reason to exist either.

In a composited environment, fullscreen windows are just maximized windows without a border, which triggers some heuristic to unredirect windows (i.e. does not have to pay the price of compositing) when they are the sole thing that is drawn on the screen.

So, on Linux, fullscreen and maximized borderless are the same. Given that Windows is a fully compositing desktop as well, I wonder why the difference still exists.

> I wonder why the difference still exists.

Some legacy apps (that is, games) react very badly when they're not in full control of their window sizing, priority, input and device polling, ecc.

But what does "Windows-style fullscreen" actually do? It feels like it switches into a different video mode (even if the resolution is the same), and back when my monitor was a CRT, I could even hear a faint click inside it whenever a game entered/exited the full-screen mode. So there was definitely something special going on, but what?

Windows style fullscreen made it so that the game controlled the resolution being sent "over the wire" to the display, and as I understand it, basically gave exclusive display access to the game. This had the interesting effect of delegating all resolution scaling to the display, which was great for CRTs and often very bad on digital displays which (usually) do very muddy bilinear scaling even if being sent a resolution that was an exact integer division of the total display resolution.

The current day approach is to instead do the "large borderless window" and then do software scaling of the image in order to match the display resolution. One cool result of this is you can get much better scaling than your display would do naively. Low-res games really benefit from software integer scaling instead of "whatever scaling the display firmware does, usually making all the edges blurry".

Rescaling in software is so fast now that some graphically intense games can do per-frame scaling in order to keep per-frame latencies below a particular goal threshold, at the cost of your game losing fidelity (getting blurier). It's so common that most big-name titles now do this.