qt: event dispatcher is too slow on windows

This is the main reason that asynchronous operations (which may inclue certain QML-side layouting) are slower on Windows. I wonder if this is about general Win32 message queue, and not necessarily a Qt issue.

Fixing this issue is going to make the application much more responsive on Windows.

changed milestone to %4.0

added Component::Interface: Qt label

The event dispatcher does not seem to do anything extraordinary (https://github.com/qt/qtbase/blob/dev/src/corelib/kernel/qeventdispatcher_win.cpp).

Qt seems to be delaying its own posted events on Windows, where I assume includes delayed bindings and queued connections [1]:

        // Start a timer to deliver posted events when the message queue is emptied.
        sendPostedEventsTimerId = SetTimer(internalHwnd, SendPostedEventsTimerId,
                                           USER_TIMER_MINIMUM, NULL);

It prioritizes other event types. And the timer used to delay seems to be USER_TIMER_MINIMUM, which is 10. Does this mean queued connections are delayed by 10 milliseconds? If that is the case, this seems a really bad idea to me because a GUI application would almost always have messages in the queue (consider input messages such as mouse move)...

These commits are suspicious:

https://github.com/qt/qtbase/commit/81408c0e76616b127c46779dc14bbcf084a3d87b

QEventDispatcherWin32: avoid livelock in a foreign event loop

According to Windows docs, GetMessage() function retrieves the messages
from the input queue in defined order, where posted messages are
processed ahead of input messages, even if they were posted later.
Therefore, if the application produces a posted event permanently, as
a result of processing that event, user input messages may be blocked
due to hard CPU usage by the application.

It's not a problem, if an internal Qt event loop is running. By calling
sendPostedEvents() on the beginning of processEvents(), we are sending
posted events only once per iteration. However, during execution of
the foreign loop, we should artificially lower the priority of the
WM_QT_SENDPOSTEDEVENTS message in order to enable delivery of other
input messages.

To solve the problem, it is proposed to postpone the
WM_QT_SENDPOSTEDEVENTS message until the message queue becomes empty,
as it works for the internal loop.

https://github.com/qt/qtbase/commit/e0d80167c18b5a71acf4dac59f3e6f37292fa397

QEventDispatcherWin32: fix posted events delivering

To avoid livelocks, posted events should be delivered when all pending
messages have been processed, and the thread's message queue becomes
empty. Although the logic of the previous patch is correct, it turned
out that determining the moment when the message queue is really empty
is not so simple. It is worth noting that the GetQueueStatus function
sometimes reports unexpected results due to internal filtering and
processing. Indeed, Windows docs say that "the return value from
GetQueueStatus should be considered only a hint as to whether
GetMessage or PeekMessage should be called". Thus, we cannot rely on
GetQueueStatus in unambiguous logic inside the qt_GetMessageHook.

To solve the problem, this patch introduces a guard timer which
guarantees low priority processing for posted events in foreign loop.
The wakeUps flag reset logic has also been changed to provide clearer
synchronization of the Qt internal loop.

[1] https://github.com/qt/qtbase/blob/6.8.2/src/corelib/kernel/qeventdispatcher_win.cpp#L220

I have created this issue: https://bugreports.qt.io/browse/QTBUG-133811.

assigned to @fuzun

mentioned in merge request !6925