Not possible anymore to get "real" fullscreen display with OpenGL in Pygame 2 (3619)

[GalacticEmperor1]

Issue №3619 opened by fladd at 2022-12-16 15:02:27

In Pygame 2 it is currently not possible anymore to get a "real" fullscreen OpenGL display (i.e. a fullscreen created with the SDL_WINDOW_FULLSCREEN flag. Due to the code [here](https://github.com/pygame/pygame/blob/75f6251910b0e2e654c1554244fa1ed88186e366/src_c/display.c# L942), Pygame will always create a "desktop" fullscreen window instead (i.e. created with the SDL_WINDOW_FULLSCREEN_DESKTOP flag) when the windows size corresponds to the entire display size.

The problem with "desktop" fullscreen windows is that under Windows 10 (and possibly under Macos as well) they are subject to the desktop compositor, which forces triple buffering. Only "real" fullscreen displays will bypass the desktop compositor and hence obey a request for double buffering (i.e. the pygame.DOUBLEBUF flag).

This is a significant deviation from the behaviour of Pygame 1 (which only knew about "real" fullscreen displays), and hence contrary to the comment [here](https://github.com/pygame/pygame/blob/75f6251910b0e2e654c1554244fa1ed88186e366/src_c/display.c# L933), in fact does break compatibility.

Having a forced triple buffer is problematic as it has the same negative consequences for other established scientific software products that rely on Pygame, as forcing adaptive vsync does, which I have described [here](pygame/pygame#3609 issuecomment-1354954957).

---

Comments

# # fladd commented at 2022-12-16 15:05:06

To be clear, I am in principle fine that the defaults have changed in Pygame 2, but there should at least be a way to get the old behaviour back via an option. Currently, there is no such option.

---

# # MyreMylar commented at 2022-12-16 19:28:22

We could have an additional pygame flag here that forces pygame to use true full screen called something like FORCE_TRUE_FULLSCREEN. This would then bypass this block:

if (flags & PGS_FULLSCREEN) {
    if (flags & PGS_SCALED) {
        sdl_flags |= SDL_WINDOW_FULLSCREEN_DESKTOP;
    }
    else if (w == display_mode.w && h == display_mode.h) {
        /* No need to change physical resolution.
            Borderless fullscreen is preferred when possible */
        sdl_flags |= SDL_WINDOW_FULLSCREEN_DESKTOP;
    }
    else {
        sdl_flags |= SDL_WINDOW_FULLSCREEN;
    }
}

...of the current sensible defaults and just do sdl_flags |= SDL_WINDOW_FULLSCREEN; e.g.

if (flags & PGS_FORCE_TRUE_FULLSCREEN){
    sdl_flags |= SDL_WINDOW_FULLSCREEN;
}
else if (flags & PGS_FULLSCREEN) {
    if (flags & PGS_SCALED) {
        sdl_flags |= SDL_WINDOW_FULLSCREEN_DESKTOP;
    }
    else if (w == display_mode.w && h == display_mode.h) {
        /* No need to change physical resolution.
            Borderless fullscreen is preferred when possible */
        sdl_flags |= SDL_WINDOW_FULLSCREEN_DESKTOP;
    }
    else {
        sdl_flags |= SDL_WINDOW_FULLSCREEN;
    }
}

---

# # ea7kir commented at 2022-12-17 11:44:10

If I ever get pygame installed on python3.11, full-screen will be very important for me too.

---

# # fladd commented at 2023-01-08 00:33:46

Seeing that the new Pygame release is still not out, could we have this very simple fix already in it once it is released? Having the ability to create proper fullscreen windows that bypass the desktop compositor is absolutely crucial for timing-critical applications.

---

# # fladd commented at 2023-01-30 20:26:34

I would also like to bring up that even when one gets a proper fullscreen window, then it seems that on MacOS it still does not bypass the compositor (or so it seems at least, as there is still some weird adaptive vsync or tripple buffering going on)!
Comparing between Pygame1 and Pygame2 on the very same MacBook I get proper normal vsync and a doublebuffer for an OpenGL surface, as requested, for Pygame1, but for the same code on Pygame2, I get some adaptive stuff going on (that is with Pygame actually failing to set adaptive vsync, as in pygame/pygame#3609, which is why I think it still goes through the compositor). In either case, I have not found a way to get a proper doublebuffered and vsynced OpenGL fullscreen window with Pygame2 under MacOS yet. Any input on how to achieve this would be very much appreciated!

[robertpfeiffer]

Hey @fladd, I'd like to explain myself, since this was my doing. This was done the way it was because

1. it was an easy way to get old games to benefit from new pygame 2.0 features without having to update each game
2. the old behaviour was less consistent cross-platform, and a bit of a foot gun for beginners
3. concrete bugs with screen recording, alt-tab, wayland, et cetera

I know that you know what you are doing (I looked a bit into the source code of expyriment), so I'm inclined to help you
and put this functionality behind a "caution: footgun inside" warning.

Nonetheless, can you please describe what kind of vsync and timing behaviour you need in a way that isn't "whatever the Pygame1.9+SDL1.2 behaviour was"? Also, what is your setup? Please don't tell me it's PyOpenGL plus PyGame on a modern M1 Mac.

[fladd]

Hi @robertpfeiffer, thanks for looking into this. I will try to explain to the best of my abilities. Expyriment is a library for implementing psychological and neuroscientific experiments. As such, it requires a very high level of timing accuracy for presenting visual stimuli. In particular, we need to know (and report to our users) the exact time the video card writes the changes to the display. Since there is no direct API to get this information from the video card directly, we make use of certain properties in OpenGL to retrieve that information. The way to achieve this for us is to: 1. Make sure that the video card does vsync (such that the video card only starts writing the content of a buffer when the vertical retrace has just happened) 2. Use an OpenGL display with a double buffer 3. Create a Pygame surface with the stimulus to present to the screen 4. Convert the Pygame surface to an OpenGL texture 5. Write that texture spanning the entire display (via PyOpenGL) 6. Do a GLBufferSwap (by calling Pygame's display.flip function) 7. Immediately after the swap, write a single transparent pixel on the display (i.e. the backbuffer, since we are using a double buffer) 8. Make a call to GLFinish (via PyOpenGL) that waits for all pending OpenGL operations to complete, before it returns The pending OpenGL operations include the writing of the single pixel. Since this can only happen once the buffer swap has occurred (because we use vsync), this will practically block the whole stimulus presentation procedure to the vertical retrace, such that when it returns, we know that the video card has actually started writing the stimulus to the display. In Pygame 1, we could achieve this pretty reliably out of the box on most machines across operating systems (Windows, MacOS and Linux), by: a. Asking the video card to do vsync by setting pygame.GL_SWAP_CONTROL to 1 b. Asking Pygame for a pygame.DOUBLEBUF | pygame.OPENGL | pygame.FULLSCREEN display In some minor cases this did not work, simply setting the video card to always vsync in the dedicated video card's settings programme (e.g. Nvidia settings panel) would do the trick. In Pygame 2, however, I quickly realised that this does not work at all anymore, on none of the operating system. Some investigation led me to realize that one culprit is that in Pygame 2 fullscreen displays by default use the new desktop fullscreen mode, which seems to just be a window with no decorations and the size of the screen. The problem with this is that those windows will be subject to the desktop compositor. This basically creates an invisible third buffer between the front and backbuffer, with the consequence that the backbuffer becomes immediately available (since it is directly given to the compositor), making the whole blocking procedure not work. Further investigation showed that under Windows (10), I can create a surface with 1 pixel larger than the display, in order to trick Pygame 2 into creating a proper (i.e. not desktop mode) fullscreen display. When I do this, I get the correct behaviour back under Windows (10)! I hence would like to ask for a way to directly ask for a proper fullscreen window, without the one-pixel-larger hack. Please also note that this only solve the problem under Windows 10. Doing the same under MacOS (10.15.7, Intel MacbookPro) for instance does not seem to work, and it looks as if the fullscreen window still is subject to the compositor under MacOS. However, on the exact same machine, Pygame 1 will work correctly and will block the way we intend to! The same is true for Linux (tested on both a Dell XPS 15 laptop and a Raspberry Pi 400). That means that in addition to the fullscreen desktop mode, there must be another difference in how fullscreen OpenGL displays are handled under Pygame 2, compared to Pygame 1, at least under MacOS and Linux. I have, unfortunately, not yet figured out what that other difference is. If you have any insights into what those other changes could be, I would be very grateful! Best, Florian

…

On Mon, Feb 13, 2023 at 5:15 PM robertpfeiffer ***@***.***> wrote: Hey @fladd <https://github.com/fladd>, I'd like to explain myself, since this was my doing. This was done the way it was because 1. it was an easy way to get old games to benefit from new pygame 2.0 features without having to update each game 2. the old behaviour was less consistent cross-platform, and a bit of a foot gun for beginners 3. concrete bugs with screen recording, alt-tab, wayland, et cetera I know that you know what *you* are doing (I looked a bit into the source code of expyriment), so I'm inclined to help you and put this functionality behind a "caution: footgun inside" warning. Nonetheless, can you please describe what kind of vsync and timing behaviour you need in a way that isn't "whatever the Pygame1.9+SDL1.2 behaviour was"? Also, what is your setup? Please don't tell me it's OpenGL plus PyGame on a modern M1 Mac. — Reply to this email directly, view it on GitHub <#1778 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWVPE6N62DIML2KXJZSFJLWXJM3LANCNFSM6AAAAAAUZOE644> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- www.fladd.de - Homepage of Florian Krause