stop fighting SDL2 resizing code

[robertpfeiffer]

The resizing API has been changed between SDL1 and SDL2. This branch implements resizing the "proper" way, according to the documentation and comments by the SDL2 team forums and bug trackers.

Instead of swallowing window events and re-requesting a pointer to the display surface every frame, we generate additional VIDEORESIZE events, and install an event watcher to automatically handle resizing. On creating a new VIDEORESIZE event, we remove the old ones from the queue. SDL2 already automatically handles resizing when SDL_Renderer is involved.

The current display surface is still automatically re-sized when a SIZE_CHANGED SDL_WINDOWEVENT is detected, but this behaviour can be disabled with pg.display._set_autoresize(False).

In that case, you must call this code, to get a valid display surface:

    if event.type==pg.VIDEORESIZE:
        screen=pg.display.get_surface()

Otherwise, the display surface is updated automatically, and you can just query the new size like this:

    if event.type==pg.VIDEORESIZE:
        screen_width, screen_height = screen.get_size()

If you're using SCALED or SDL_Renderer directly, there is no need to call anything on resize, and there is no more reason to make expensive calls to pygame.display.set_mode() for every VIDEORESIZE event any more.

[nthykier]

Looks like it would fix #1671 as well.

[nthykier]

I spotted two compiler warnings that I think we should fix.

[nthykier]

With this branch, I notice a weird resize in the Endgame: Singularity game

On resize, it is sometimes "stuck" with a larger window that is not properly redrawn (see the bottom and the right side of the window). I suspect we are swallowing an event too much here. But at last the "wobbly" resizing effect appears to be gone.

[robertpfeiffer]

With this branch, I notice a weird resize in the Endgame: Singularity game

I'll have to look into this game to tell you what's going on. Maybe we'll need to emulate the old beaviour by default (do not resize display surface in flip, let user handle VIDEORESIZE) and switch to new resize behaviour when requested (do not resize display surface in flip, invalidate automatically, user must handle SIZE_CHANGED).

In any case, only issuing one VIDEORESIZE at a time and only allowing one of them to be in the queue at the same time is the right thing to do.

[robertpfeiffer]

The tests run through (click on the travis and appveyor links), but I haven't yet added an interface to disable the legacy resizing behaviour or investigated the bug in singularity.

[nthykier]

The tests run through (click on the travis and appveyor links), but I haven't yet added an interface to disable the legacy resizing behaviour or investigated the bug in singularity.

Thanks. :)

For singularity, you would need to look at the master branch and you can find the code at https://github.com/singularity/singularity. Note that no released code of singularity the resize code, so I am happy to rewrite the singularity resizing code as long as there is a way to support both SDL1 and SDL2 resizing.

[robertpfeiffer]

as long as there is a way to support both SDL1 and SDL2 resizing.

That should be easy enough. If we add a way to disable generation of VIDEORESIZE events from SDL2 SIZE_CHANGED events, you can listen for SIZE_CHANGED events instead.
Of course, SIZE_CHANGED is not a thing in SDL1.2 or pygame 1.9.6, so it's not backward compatible.

[nthykier]

My tests so far:

• The default works under pygame2/SDL2 in singularity. It occasionally gets the resize slightly wrong and in correctly renders artefacts as shown previously, but the resizing is generally smooth. So a net improvement since the last review.
• When using pygame.event._set_gen_videoresize(False), then resizing stops working for me. The display is updated but the application is not notified of the change and still renders on its old (cached) window size. AFAICT, there is no new event to listen for (and VIDEORESIZE disappears), but it sounded like there should be a new SIZE_CHANGED event.

[illume]

Looks like there's some conflicts with the recently merged SCALED PR.

[robertpfeiffer]

@illume I am 90% sure the CI is broken, but I'll need to re-test the code anyway in its current state

[nthykier]

I could do with an example of how an application in Pygame 2/SDL 2 can get notified about being resized (so it can update its understanding of how large the window is and repaint the difference) when using the "newstyle resizing" (VIDEORESIZE is called legacy as of these changes, so I assume the newstyle should react to a different event)

Beyond that, I think this is a net improvement and I presume it would deal nicely with #1492.

[illume]

Did some testing on MacOS and windows...

MacOS catalina SDL 2.0.12, metal:

• setmodescale.py works nicely resizing.
• eventlist.py is working better than before. The slowness of resizing is gone. But the screen surface still gets corrupted. when clicking the maximize button goes into fullscreen, then pops into a full-desktop sized window, the other ones go into fullscreen mode and stay there.
• resizing_new.py seems to work ok
• I'm getting a GLError with the glcube example, unrelated to the resizing branch.

Windows 10 home, SDL 2.0.12:

• setmodescale, and eventlist work ok. There's no corrupted display with eventlist like on MacOS.
• resizing_new.py seems to work ok
• glcube resizes ok with RESIZABLE, and with RESIZABLE | SCALED. With SCALED it starts a bit too big. The window is placed maybe 20 pixels or so above the top of the screen.

[illume]

👍 🎉 thanks :)

@nthykier are you happy with it now?

[nthykier]

I think I still missing a "This is how you are supposed to do resizing with SDL 1 vs. SDL 2 when the game needs to be notified of resizing" before I can review it any further.

[nthykier]

(my comment still stands, but I do not want to be holding this PR back as it is probably a lot better than status quo)

[illume]

I think I still missing a "This is how you are supposed to do resizing with SDL 1 vs. SDL 2 when the game needs to be notified of resizing"

Ok, let's look at this in another PR :)