On X11, if paint operations fall significantly behind, performance is trashed

This issue is very often encountered with Qt5 on X11:

• Performance is fine while time spent painting in the main thread remains below 1/screen_refresh_rate. Widgets update normally.
• As time required to paint increases linearly, a threshold is reached. At this threshold, a slight increase in time spent painting results in a huge and unexpected loss of apparent performance. Widgets are seen to update 1/5th to 1/10000th as often as they were on the other side of the threshold. This issue does not exist in Qt4, and is not seen with Qt5 on Win32 or OS X.

The issue can even be seen with Qt5 on X11 in Qt Assistant: maximize Qt Assistant on a high-resolution display, load a long entry such as the documentation for QObject, reduce the font size so as to increase the amount of text visible on the screen, and drag the scrollbar up and down slowly at first and then with increasing rapidity. While the scrollbar is moved slowly, Qt Assistant can be seen to repaint at native refresh rate. As the scrollbar is moved more quickly, repaint frequency drops off remarkably and continues decreasing yet more as scrolling rate increases until, finally, Qt Assistant does not update at all until some time after scrollbar manipulation ceases.

I am attaching a test case that may offer some insight into the issue.

Running the test case with an argument of 5000 and then rapidly moving the mouse pointer around the test case application's window has profoundly different results in X11 vs OS X and Win32.

On Win32 and OS X, TestScene::mouseMoveEvent calls generally coincide with visible updates to the application window. Moving the mouse more rapidly does not further reduce framerate or increase the rate of TestScene::mouseMoveEvent invocations.

On Linux with X11, ramping up mouse movement crosses a threshold beyond which a very large number of TestScene::mouseMoveEvent invocations occur without associated window repaints. The application window updates once in a long while, although TestScene::mouseMoveEvent invocations occur more rapidly than ever. Further increasing mouse movement speed results in ever more TestScene::mouseMoveEvent invocations and even fewer window updates.

In summary, with Qt5 in X11, input events that trigger deferred repainting pile up and continue piling up if painting is too slow, while visible screen updates happen less and less often and eventually cease entirely until the input queue is consumed. The problem is not limited to QGraphicsScene stuff or QWidgets, but does happen only on X11, pointing to a regression caused by changes to event handling Qt's X11 event handling code - for example, as an educated guess, moving to XCB and placing input event reception in a thread other than the main GUI thread, allowing input events to queue up, with the additional wrinkle that a buffer rendered for an event too far back in the input queue is thrown away, thereby causing the GUI to appear frozen until the input queue empties.

In any case, this issue is responsible for critical performance regressions experienced between Qt4 and Qt5 by Linux users in the scientific computing community, including the almost total loss of interactivity in Matplotlib seen on Linux with X11 and Qt5 as compared to with Qt4.