fix the red flashing during live resize #1418
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
allefant
changed the title
|
Only deferring setFrameSize after a resize now. |
|
After discussing with Mark Oates on IRC I think the reason it works with the SDL port may simply be the fact that Allegro's SDL port is single threaded - only ALLEGRO_MACOS uses the special main addon, ALLEGRO_SDL does not. With a single thread we obviously can never violate the serialized OpenGL commands requirement. |
|
On my new system I get a repeatable crash in ex_resize2 with or without this change as soon as I resize a window: |
I only have an old Intel Mac - maybe they replaced the red flash with an outright crash for Apple silicon. I can at least try upgrading to the newest version maybe i can reproduce with that. |
|
For completeness, sending HALT/RESUME_DRAWING events from |
SiegeLord
pushed a commit
to SiegeLord/allegro5
that referenced
this pull request
May 21, 2023
Elias investigated the issue in liballeg#1418, showing that there was some concurrent OpenGL usage between OS's internals and user code. That specific workaround did not work for me on my Mac, so as an alternative, in this commit we add an option to bypass live resize altogether. In short, the user opts into drawing halt/resume events via a config option, and ceases to draw while live resize is underway. This isn't ideal, but at least is a way to prevent the crashing behavior until we find some better idea.
|
Just found godotengine/godot#54519, but the fix there doesn't seem to work for me (they didn't seem to like it either, as it caused artifacts for them). |
SiegeLord
pushed a commit
that referenced
this pull request
Sep 13, 2023
Elias investigated the issue in #1418, showing that there was some concurrent OpenGL usage between OS's internals and user code. That specific workaround did not work for me on my Mac, so as an alternative, in this commit we add an option to bypass live resize altogether. In short, the user opts into drawing halt/resume events via a config option, and ceases to draw while live resize is underway. This isn't ideal, but at least is a way to prevent the crashing behavior until we find some better idea.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I did some more digging about the broken live resize under MacOS reported in #1350. Tracing through a resize in ex_resize2 in lldb the following happened:
I think flutter works around this in some complex way involving an off-screen drawable unaffected by the out-of-sync glViewport call, but not really sure. I think SDL works around it by a) not offering live resize and b) somehow not having an OpenGL context on the main thread at all, but I don't fully follow their code either.
I think it would be best if we disable live resize entirely as it's a useless feature, but this PR still seems to be needed even then since MacOS still makes that asynchronous glViewport call for its live-zoom effect... I almost feel we use some setting somewhere which makes MacOS auto-resize the GL viewport, but I couldn't find anything obvious. Anyway, if there's no better ideas I'll try and fix the setFrameSize() issue, probably with a hack using the windowWillResize() notification to know when the next setFrameSize() needs to be ignored...