BACKENDS: MACOSX: When switching between windows created with different graphics types, both may be retained as active windows.

[macca8]

ScummVM’s graphics types can be broadly categorised as Surface SDL, OpenGL or 3D OpenGL. When switching between any of these types, either by changing the Graphics Mode setting or switching between game and Launcher windows, the old window isn’t always completely destroyed when the new window is created.

This appears to be an issue between macOS and later versions of SDL2, though which is the earliest SDL2 version to trigger this behaviour isn’t known. It applies to some degree to all current development, stable & release builds, except the 32-bit v2.2.0 release.

For affected builds, the observed behaviour is as follows:

• By default, both new & any retained old windows are listed as currently active in the app’s Window Menu, however only the new window is displayed on-screen.
• An old window can be viewed by choosing it from the Window Menu, then deactivated by choosing another window, in which case it remains visible on-screen as a normal open window (but see next point).
• Generally, an old window is displayed as a black window, complete with an inactive title bar. It can be moved by dragging the title bar, but not resized or closed. However, especially with some game windows, the old window may also present as invisible, in which case no interaction is possible when 'revealed' on the desktop.
• Any open windows - including invisible windows - previously accessed from the Window Menu can be viewed collectively by right-clicking the app’s Dock Item and choosing Show All Windows from its menu.
• Retained old windows (there’s no limit) can only be deleted from the desktop and/or menu by quitting the app.

See attached screenshots for examples of Window Menu, Dock Item Menu & desktop images.

Criteria for reproducing this issue:

• The basic requirement is that the current graphics type changes to a different type when the new window is created (to or from OpenGL, 3D OpenGL, or Surface SDL).
• Use explicit settings for window types dependent on the Graphics Mode option (i.e. Launcher & 2D games), for example, OpenGL or Surface SDL normal2x (or 2x if testing builds that predate changes unique to current development builds).
• Switches between Launcher & game (either 2D or 3D) require that the new window also changes the screen mode as part of the switch (suggested setup: windowed Launcher & fullscreen game).

To test, as a minimum, either:

• Change the Graphics Mode setting to or from OpenGL (try both directions), or
• Load a game from the Launcher, then return to the Launcher (recommend 3D for development builds, 2D for stable & release builds).
• The app’s Window Menu can be accessed either by changing screen mode while in-game or from the Launcher.

Please note:

• Switches between different Surface SDL scalers are NOT affected by this issue.
• Results can vary depending upon which Graphics Mode is applied to the Launcher (OpenGL or Surface SDL).
• The issue may not be triggered until a subsequent switch, if no previous switches have been performed since the app was launched.
• The criteria for testing 2D games can be applied to development builds, but switches between game & Launcher and when using Alt+Enter in-game, can produce unexpected transitional behaviour, which appears to be unrelated to this issue. Provides a valid test, but this configuration not recommended for regular usage.

Tested on an Intel Mac with a 1920x1080 screen, running macOS 10.11.6.

[criezy]

Finally a bug that I can partially reproduce!
But only partially... And only once...

With my own build using SDL 2.0.14, the first time I tried to reproduce I indeed got two windows listed in the Windows menu after I switched from OpenGL to Surface SDL graphics mode. Switching multiple times did not add more windows. It looked like it had one window for each of the two graphics mode.

However I only ever had one window visible. Selecting the other window in the Windows menu removed the focus from the active ScummVM window, but did not show the other window.

And now I can't even reproduce that issue with the window list. I can switch between OpenGL and Surface SDL, start a 3D game, come back to the launcher. Whatever I do I only have one window listed in the Windows menu.

This sounds like a libSDL bug. In ScummVM we do call SDL_DestroyWindow before recreating a new one with SDL_CreateWindow, which seems correct to me.

[macca8]

Thanks for testing! Your results identified a pattern that prevents the first switch after a change from triggering the bug, so I’ve devised a simpler test that changes the sequence of events and should give more consistent results.

Set the Launcher to windowed mode, set a 3D game to fullscreen (I tested with Myst3, with the widescreen mod engine option disabled), and enable the Return to Launcher at Exit option. Start with the graphics mode set to either OpenGL or Surface SDL (leave the scaler set to default).

The test sequence is:

• Click start to launch a 3D game’s start screen (or load a saved game), then quit back to the Launcher.
• Repeat the previous action.
• Switch the Launcher’s graphics mode from OpenGl to Surface SDL (or vice versa, depending on its current setting), then click Apply to confirm the change.
• Return to the Launcher, then repeat the first two steps.
• Switch the Launcher’s graphics mode to the opposite setting, then click Apply to confirm the change.

If you check the Windows Menu (or check it progressively after each step) you should now see two game windows & three Launcher windows listed, the last being the current window. If by chance only one game window is listed, launch and quit the game two more times to add the extra game window.

In this sequence, Launcher windows are retained only when the graphics mode setting is changed (launching the game doesn’t retain the Launcher window), and game windows are retained only if the game returns to the Launcher more than once since the graphics mode was changed.

If you still can’t reliably reproduce the issue, then I’m at a loss. The good thing is that it appears to be harmless, and most users probably wouldn’t even be aware of it.
In either case, it can probably be ignored and considered an anomaly.