macOS event dispatching broken

[TheJJ]

#828 figured out that for a successful mac run the event dispatching for mac needs to be changed.
This has to be fixed properly.

[Birch-san]

Useful references…

• The pull request #756 GUI: Also try a separate-shared-context mode where the magic commit was first considered
• The magic commit

#756 (comment):

@Birch-san, we also discussed in this PR some changes to the input handling (in outdated comments): libopenage/gui/guisys/private/gui_application_impl.cpp and libopenage/gui/guisys/private/gui_event_queue_impl.cpp.

Dropped that commit because it was unexplainable. I've put it here:

VelorumS@d577f56

• undo final change of gui-gl-context pull request, to prevent SIGSEGV #828 (comment):

[ChipmunkV] that magic partially disables input handling, so it needs some work: #819 (comment)

• make compiler issues on os x Yosemite. #819 (comment):

[Birch-san] @ChipmunkV, I know you've said that the commit was removed because it was unexplainable. But where did you get the idea to do that? Did you read something somewhere?

[ChipmunkV] @Birch-san, I knew that event loops in Qt use event dispatchers that have OS-specific implementation. Then you just disable the input handling part and try.

I think that the issue is easily fixable by implementing and installing a custom dispatcher with QCoreApplication::setEventDispatcher().

[Birch-san]

I actually had a stab at ChipmunkV's idea (installing a custom dispatcher):

master...Birch-san:set-event-dispatcher

I have no idea what I'm doing. At the time of writing: my custom event dispatcher compiles, and openage runs, but we still have a white screen followed by a black screen.
Edit: I just added some qWarning() lines to check whether any functions of my event dispatcher are being invoked. They are never invoked. setEventDispatcher() needs to be installed before you init the QCoreApplication — and I thought I'd done that — but apparently this isn't the correct way to install an event dispatcher.

A good reference for how to build a custom event dispatcher is here (MIT License, peper0@GitHub):

https://github.com/peper0/qtasio/blob/master/qasioeventdispatcher.cpp
https://github.com/peper0/qtasio/blob/master/qasioeventdispatcher.h

Note: peper0's code includes private headers such as:

#include "private/qabstracteventdispatcher_p.h"
#include "private/qtimerinfo_unix_p.h"

We're not supposed to do that. It has the following message:

This file is not part of the Qt API. It exists purely as an
implementation detail. This header file may change from version to
version without notice, or even be removed.

We mean it.

I think we can live without those private headers anyway. qabstracteventdispatcher_p.h is basically empty. qtimerinfo_unix_p.h is more substantial, but whatever. We may not implement event dispatch in exactly the same way, so not sure how useful it is to us.

[Birch-san]

I also considered "maybe a custom event dispatcher is overkill. could we just filter out events instead?"

master...Birch-san:event-flags

I believe no matter what combination of events that I filtered out: I still ended up with a black screen, and the animated graph never appeared. These are the notes that I took at the time:

WARN QFlags(0x1|0x2|0x4) = no graph
WARN QFlags(0x2|0x4) = no graph
WARN QFlags(0x4) = no graph
WARN QFlags(0x1|0x2) = no graph
WARN QFlags(0x1) = no graph
WARN QFlags(0x2) = no graph
WARN QFlags(0x1|0x4) =

Maybe I should've also tried filters on gui_event_queue_impl.cpp, rather than just on gui_application_impl.cpp.

[Birch-san]

There's also this:

• QCoreApplication::installNativeEventFilter
• QAbstractNativeEventFilter::nativeEventFilter

I wonder if the event dispatch problem is just with some platform-specific events. So maybe we could see some change if we filtered them out.

[Birch-san]

Btw, the magic commit is no panacea. This is a video of what openage looks like with the magic commit:

https://www.youtube.com/watch?v=9GmwKreWg6I

Ignore the blue tint — that's an endianness problem that is now fixed.
Rather, notice that loads of interface elements disappear/reappear all the time.

#756 (comment):

[ChipmunkV] A theory about the disappearing buttons: it's probably related to that input handling fix - some events can't pass through if there is not enough real input activity (so the GUI isn't updated).

[VelorumS]

Btw, I've started the event dispatcher too. And probably I've started from that piece of code where it's created (to make sure that it's created before the QApplication).

The gui_dedicated_thread.cpp that you're changing is a dead code for the future case where the GUI event loop is separated from the rendering thread (sorry about that, it's not a good practice to leave stuff "for the future" on the main branch).

The possible places to attach a dispatcher are: libopenage/gui/integration/public/gui_application_with_logger.cpp (the logger is also attached before the QApplication is created) or libopenage/gui/guisys/private/gui_application_impl.cpp.

About the events: the OS-level event loop is handled by SDL, input events for Qt are synthesized by the openage from the SDL events. There shouldn't be any way for the events from OS to get into Qt.

edit: actually, haven't done much at all - https://github.com/ChipmunkV/openage/commits/event-dispatcher

[Birch-san]

I continued to investigate this.

I've put useful stuff into this branch, you can comment out bits that you don't want to use:

master...Birch-san:event-dispatch-2

The main things that you may find yourself commenting out are:

• gui_application_impl.cpp: installation of the custom event dispatcher (because it's no-op)
  • remove app{(QCoreApplication::setEventDispatcher(&this->event_dispatcher), argc), &argv}
  • prefer app{argc, &argv}
• the logging that is performed in my event filters (because they're noisy; depends if that's what you're testing)
  • remove KeyPressEater.cpp qInfo() << "EVENT: " << event->type();
  • remove CocoaNativeEventFilter.cpp qInfo() << "NATIVE EVENT: " << eventType << "; " << [event type];
• gui_application_impl.cpp: installation of the native event filter (if you're testing this on non-macOS for some reason, and can't compile Objective-C):
  • remove this->app.installNativeEventFilter(&this->native_event_filter);

I've demonstrated here:

• how to install an event filter
  • currently I just use this to log events
• how to install a native macOS event filter
  • currently I just use this to log native events
• what a no-op event dispatcher looks like
  • installed using @ChipmunkV's technique

Things that I noticed…

• When GuiApplicationImpl invokes QGuiApplication#processEvents(): it never finishes.
  • well, maybe this is what it's supposed to do?
• When GuiEventQueueImpl invokes QEventLoop#processEvents(): it never finishes.
  • well, maybe this is what it's supposed to do?
• I tried setting a 100ms maxtime on processEvents: this->app.processEvents(QEventLoop::AllEvents, 100);
• this did not help (the function call still never finished).
• Similarly: I tried toggling various event flags (as I mentioned in an earlier comment), one of which isQEventLoop::WaitForMoreEvents. No combination that I tried did anything. I tried on both processEvents() invocations.
• If either of those classes invokes their processEvents(): we will never again see any events logged in our event filter.
  • probably this means we never process any QTimer events. I assume this is why the graphics don't update.
  • we do continue to see native events (mouse move, keypresses) logged in our native event filter
  • maybe I'm interpreting this incorrectly though. perhaps processEvents() isn't meant to pass events through the filter first?
• I tried filtering out all events and all native events. This did not solve any problems.
  • So this means there's no "bad event" that the event dispatcher fails to handle.
• QThread::currentThread() == QCoreApplication::instance()->thread() is always true, as far as I noticed
  • this logic was used by the "magic commit" to ensure that processEvents() was never run on the QCoreApplication's thread
  • in practice: I think it just means that processEvents() is never run, ever.
  • the reason this helps is because processEvents() seems to be broken in some way with the default macOS event dispatcher.

In case you're interested, this is what I observe when I use the no-op event dispatcher:

• If processEvents() is run: we see neither events, nor native events logged in our event filter
• If processEvents() is not run:
  • we see both events and native events logged in our event filter
  • we see the real-time graph, but nothing else:

So, that's various things that didn't work.

I do caution that writing a custom event dispatcher could be very hard. Here's qt5/qtbase/src/corelib/kernel/qeventdispatcher_cf.mm, which I assume is Qt's default event dispatcher implementation for macOS (i.e. it's the only one that I see written in Objective-C).

I see that Qt5 has the following event dispatcher implementations:

qt5/qtbase/src/corelib/kernel/qeventdispatcher_cf_p.h
qt5/qtbase/src/corelib/kernel/qeventdispatcher_cf.mm
qt5/qtbase/src/corelib/kernel/qeventdispatcher_glib_p.h
qt5/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp
qt5/qtbase/src/corelib/kernel/qeventdispatcher_unix_p.h
qt5/qtbase/src/corelib/kernel/qeventdispatcher_unix.cpp
qt5/qtbase/src/corelib/kernel/qeventdispatcher_win_p.h
qt5/qtbase/src/corelib/kernel/qeventdispatcher_win.cpp
qt5/qtbase/src/corelib/kernel/qeventdispatcher_winrt_p.h
qt5/qtbase/src/corelib/kernel/qeventdispatcher_winrt.cpp

Maybe we could use the UNIX one or the glib one somehow. But I assume the macOS one exists for a reason.

Some of this stuff is private, so it may be non-trivial to copy-paste. Maybe we can construct an instance and delegate to it?

You can have a look at that source like so:

git clone git://code.qt.io/qt/qt5.git
cd qt5
git checkout v5.8.0
cd qtbase
git submodule update --init --recursive .

But seriously I've no idea what I'm doing.

[Birch-san]

https://doc.qt.io/qt-5/qeventloop.html#exec

More sophisticated idle processing schemes can be achieved using processEvents().

Do we definitely need to use QEventLoop::processEvents()? could we switch to something like QEventLoop::exec()? sounds like it's less complex. if it meets our requirements: perhaps using it would randomize the situation enough that the problem disappears.

[VelorumS]

That's where I'm at: VelorumS@13ad763

The most relevant part is libopenage/gui/guisys/private/gui_timer_info.cpp. Need to make it work so the dispatcher can process timers. That will probably be enough.

QGuiApplication::processEvents, QEventLoop::processEvents and QEventLoop::exec call our QEventDispatcherImpl::processEvents on Linux for me. I'll try your code.