OPENGL: Alt+Enter misbehaves in OpenGL mode on MacOS

[angstsmurf]

When going from fullscreen to windowed mode by pressing alt+enter in OpenGL mode, the game window won't return to its original size that is has when started in windowed mode, but will be scaled to twice the size, filling most of the screen.

The other graphics modes seem to work correctly.

This is on a retina Macbook Pro, MacOS 10.12.5 and ScummVM 1.10.0git3777-gec37d2002c (Jul 11 2017 19:52:00).

[csnover]

What game are you running when this happens? Is the game set up to override the global OpenGL graphics mode setting with some other mode? I haven’t been able to reproduce this, so more information (like a specific set of steps to take to reproduce the bug) would be helpful.

[angstsmurf]

RIght, sorry about the lazy report. This is with ScummVM 1.10.0git3962-g850dcdbdf8 and MacOS Sierra 10.12.5, on a Retina MacBook Pro, 15 inch, mid 2014.

Start ScummVM in OpenGL, Modern theme, windowed mode. Click the Options button, check the Fullscreen box, click OK. At first it looks fine for a moment, a second perhaps, then the ScummVM GUI jumps upwards, partly off-screen.

I wish I had a good screen recorder to show this.

[angstsmurf]

The jump seems related to the size and position of the Scummvm GUI window in windowed mode, before going fullscreen. If I pin the dock to the left and let the ScummVM GUI window fill the rest of the screen before going fullscreen, the fullscreen GUI jumps to the right instead of up. So it seems like the screen coordinates calculation in fullscreen shifts the entire screen by the origin of the non-fullscreen window, if that makes any sense at all.

[angstsmurf]

Also note that if I leave the fullscreen GUI by pressing Alt+Enter instead of unchecking the Fullscreen box, the GUI settings get confused and still has Fullscreen checked in windowed mode. But this is probably unrelated and something that should be reported as a separate issue.

[angstsmurf]

Another probably separate issue is that the GOG/FM Towns Zak McKracken shows a black screen (but with working music) when starting in windowed OpenGL mode, while it works fine in fullscreen.

[criezy]

I can't reproduce this issue either. For me switching between windowed and fullscreen modes seems to work correctly will all the cases I have thrown at it. My MacBookPro does not have a retina display however, so the issue might be there.

Can you give a bit more precisions on the ScummVM version you used: is it one of our daily builds? Or did you compile it yourself? If you compiled it, which SDL version did you use?

[angstsmurf]

Yes, I compiled this myself. When running the configure script, it says "Backend... sdl (2.0.5)", which I assume is the SDL version it uses.

./scummvm --version
ScummVM 1.10.0git3962-g850dcdbdf8 (Jul 16 2017 23:46:28)
Features compiled in: TAINTED Vorbis FLAC MP3 SEQ TiMidity RGB zLib MPEG2 FluidSynth Theora AAC FreeType2 JPEG PNG cloud (servers, local)

[angstsmurf]

You're right, it seems to work fine in the daily builds. Well, apart from those last two probably unrelated issues I mentioned. Do the daily builds use a different SDL?

[criezy]

Daily builds use an older SDL version (1.2.14). And I used 2.0.4 for my tests. I will try to get 2.0.5 to check that this is not an issue introduced in that version. If the issue is with the way SDL2 handles retina display, it will be difficult for me to take a look.

[criezy]

I have now tried with SDL 2.0.5, and it still works as expected for me.

[angstsmurf]

Well, at least we know what the likely cause is. Please let me know if there is anything I can do to help.

[csnover]

OK, I don’t seem to have a lot of patience to do research on this right now, but I have reproduced the issue on macOS 10.11.6 using one hi-dpi monitor (on the left) and one standard monitor (on the right), with “Displays have separate Spaces” turned on in Mission Control. The GUI is messed up spectacularly in different ways depending upon hardware configuration:

1. With just the hi-dpi monitor connected, the GUI doesn’t actually know how to draw with proper scaling, so the UI is rendered lo-dpi but using the retina display resolution (so all the elements are tiny).

2. With lo-dpi monitor + hi-dpi monitor, where the hi-dpi monitor is used as a secondary screen, when switching to full-screen mode with ScummVM on this secondary screen it ends up drawing on the primary screen with the wrong y-resolution so the GUI elements get cut off.

3. With lo-dpi monitor + hi-dpi monitor, where the hi-dpi monitor is used as a primary screen, when switching to full-screen mode with ScummVM on this primary screen it ends up with a negative left and bottom offset so ends up drawing off the bottom-left side of the screen.

Even when forcing ScummVM to open in low-resolution mode, these problems continue to exist; I guess the OpenGL renderer is bypassing that mode setting and requesting a hi-dpi surface. (I don’t know anything about OpenGL at the moment to know what this might be.)

(Tangentially, in all cases, performance of the GUI with OpenGL backend is _abysmal_. It takes up to 10 seconds just to render the GUI after switching to fullscreen, and then the mouse cursor won’t move for several seconds after that. Every time a new dialog opens it takes 6+ seconds to render. This problem is resolution-dependent, even at 640x480 it gets janky when clearing the modals. The performance is so bad I feel like recommending that OpenGL get disabled entirely on this platform in the next release if this problem isn’t fixed.)

I haven’t tried disabling separate Spaces yet to see how that might change things but I am guessing it would only make things worse.

The first idea I have to solve this ticket is to stop using SDL_SetWindowDisplayMode API and see if we can’t do OpenGL fullscreen using fake fullscreen at least on macOS.

[angstsmurf]

This seems to be fixed after updating SDL2 to 2.0.6.

[criezy]

From this feedback we will assume then that this is a bug in SDL2 with retina displays and that it is fixed in SDL 2.0.6.
I have just updated my toolchain for the release to use SDL 2.0.6, so hopefully the next release will work correctly.