Consume all events in the event queue to avoid application lockups #300
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
fniephaus
added a commit
that referenced
this pull request
Mar 2, 2020
@guillep introduced some additional logic to filter out events that do not correspond to the VM window. The about panel and the fullscreen frame are also alien windows, but were not receiving any events because of this change. As a consequence, these events will forever remain in the queue and therefore, the buttons of the fullscreen frame and about panel cannot be clicked. This commit reverts all changes back to the previous version that consumes all events and forwards them to NSApp. In order to avoid breaking PharoVM, we do all of this behind an `#ifdef PharoVM`. Relevant changes: #295 #300
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.
It seems that "peeking" from the event queue does not yield events in case of changing resolutions:
And then it never enters the loop...
Of course, apple's doc says nothing about this: https://developer.apple.com/documentation/appkit/nsapplication/1428485-nexteventmatchingmask?language=objc
So all this is speculation ^^.
This new version consumes all pending events in the NSApp, and it does not show any lockups when e.g., switching resolutions. If the event does not correspond to this window, we take it from the event queue anyways and re-post it afterwards, to give other windows the opportunity to consume their events.