Opened 3 years ago

Last modified 2 years ago

#13054 new defect

MACOS: OPENGLSDL: Maximizing a window doesn’t set SDL_WINDOW_MAXIMIZED flag.

Reported by: macca8 Owned by:
Priority: normal Component: Port: Mac OS X
Version: Keywords:
Cc: Game:


Pressing the window title bar’s green button to maximize a window expands the window to fill the screen as expected, but registers in the config file as window_maximized=false.

The test in OpenGLSdlGraphicsManager::notifyResize() determines if a window is maximized by checking if its SDL_WINDOW_MAXIMIZED flag is set. Unfortunately, in macOS, this flag doesn’t always set as expected, resulting in the test incorrectly returning false. This appears to be a known SDL bug affecting macOS, included as part of this SDL bug report (I’m running macOS 10.11.6).

What this does is incorrectly assign the maximized values to the config file’s last_window_width/height settings, instead of creating the expected last_maximized_width/height entries.

If a user exits the maximized window other than by clicking the green button, the previous values are lost, and the maximized values become the default window size. When next entering windowed mode, these values may be adjusted further, reducing the window to the maximum size allowable for an unmaximized window.

The good news is that this bug doesn’t interfere with the ability to maximize a window, so the objective here is to modify the test in notifyResize() to enable macOS to correctly identify a maximized window.

I’m no expert here, and there’s probably a simple and obvious way of resolving this test (there usually is), however, I’d like to offer a couple of suggestions as food for thought, if I may.

The style of the window when maximized (at least in macOS 10.11.6) suggests that the SDL_WINDOW_FULLSCREEN_DESKTOP flag is set. A feature of this flag is that it resizes a maximized window to the equivalent of the desktop resolution (I’ve confirmed this by checking the config file’s entries while maximized), which is always larger than the unmaximized window.

This presents two possible tests:

  • if this flag is only set when the window is maximized, add this flag to the existing test, such that if either flag is set (with priority given to SDL_WINDOW_MAXIMIZED), the test returns true.
  • alternatively, test if the window’s size equals the desktop resolution, which would also return true.

Hopefully, if this can be resolved, it may address the odd macOS behaviour identified by criezy in PR 3400.

Applies to current daily builds and the 64-bit 2.5.0 release.

Change History (4)

comment:1 by aquadran, 2 years ago

Summary: MAC OS X: OPENGLSDL: Maximizing a window doesn’t set SDL_WINDOW_MAXIMIZED flag.MACOS: OPENGLSDL: Maximizing a window doesn’t set SDL_WINDOW_MAXIMIZED flag.

comment:2 by criezy, 2 years ago

My analysis here is different from what is described in the bug report.

On all of my tests the SDL_WINDOW_MAXIMIZED flag is correctly set when using the green button to maximize the window, and the window_maximized value is correct in the config file. However this could depend on the macOS or SDL version (I am using macOS 11.6 and SDL 2.0.16).

However I still see the issue reported, but this is because we have an issue in our code that creates the window as it reduces the size to make sure the window with its borders is no bigger than the desktop size (unless we want fullscreen):

Maximized is not fullscreen, but since on macOS it is borderless, we still should not adjust the size with the border size there.

As an additional note:

The style of the window when maximized (at least in macOS 10.11.6) suggests that the SDL_WINDOW_FULLSCREEN_DESKTOP flag is set.

That is actually not the case. I checked it and a window maximized with the green button has the SDL_WINDOW_MAXIMIZED flag set for me, but not the SDL_WINDOW_FULLSCREEN_DESKTOP flag.

comment:3 by criezy, 2 years ago

The issue I flagged in my previous comment is now fixed.

But it is still not quite right. The call to SDL_CreateWindow with the desktop size and the SDL_WINDOW_MAXIMIZED flag creates a window that has the maximized flag set, but is smaller than a maximized window because the menubar is still visible.

comment:4 by macca8, 2 years ago

Just to confirm. I'm not seeing any change in behaviour following your latest commits, using 2.6.0pre1 on macOS 10.11.6.
I tested with a brand new config file, with no games installed, and manipulated the Launcher window using the green maximize button exclusively.

To view the config file when the window is maximized, I move the cursor to the bottom of the screen to reveal the Dock, then select the Finder, which slides the Launcher window off the screen.

Whether this has any effect on the window_maximized value, I don't know, but its value at this time is still false, even though last_window_width/height show 1680 x 1050 respectively.

If I toggle the green button again to return to normal windowed mode, the window is correctly restored with L_W_W/H values of 840 x 630. If, however, I quit while the window is still maximized, L_W_W/H retain the values of 1680 x 1050.

Upon restart, the app launches in windowed mode as expected, but its size is adjusted to 1660 x 925 (the new L_W_W/H values).

The window_maximized value remains false throughout, and the only other window-related entries appearing in the config file are the last_window_width/height entries.

Note: See TracTickets for help on using tickets.