QtQuick 2.0: animations cause progressive lag and to event processing

Note: this bug is probaly related to QTBUG-14102 and QTBUG-21049. This shows up on tablets, both x86 and ARM, but has not been an issue on desktops.

Touch events are not processed in time when QML scenes with animations have been running for a while. You can test this with the attached QML file, which works on current Qt5 trunk versions.

1) Immediately after starting qmlscene, touch events work
2) When qmlscene has been running for a while (1-2 min), touch events are registered with a slight delay and cause animation jitter; drawing a constant circle or figure of eight on the QML scene area will trigger the behaviour
3) When qmlscene is allowed to run longer, any touch events will cause animations to halt entirely; CPU use of qmlscene jumps to 100%
4) When the performance has degraded this far, it may take several seconds for animations to start again after finger has been lifted from touch screen; during this wait period, CPU use remains at 100%
5) The longer the scene and animations are allowed to run, the longer the event processing delay gets
6) Restarting qmlscene resets the behaviour; if X cursor is visible, touch events move the cursor regardless of whether QML scene is hung or not. This implies that the delay comes from within Qt.

The delay is apparently not related to touch event generation: if started and allowed to run for a while without touching the screen at all, the lag is already present when finger is first moved on touchscreen.

With ltrace we observed something rather weird:

• During step #1, touch events are processed normally and inline with animations
• During step #2, the first touch events are processed after a slight delay
• During step #3, touch events are not processed at all

The command we eventually used for this was:

1. ltrace -e _ZN9QSGCanvas5eventEP6QEvent -e _ZN7QSGView14mouseMoveEventEP11QMouseEvent qmlscene -platform xcb animation_test.qml

• (Apparently we can't give demangled names to ltrace.)

Touch events come in pairs of library calls: First, QSGCanvas::event() triggers, followed by QSGView::mouseMoveEvent() - although the latter dispatches the actual event processing back to QSGCanvas.

• During step #1, the library calls show up immediately
• During step #2, the calls take some time before they appear
• During step #3, the calls appear only after no further touch events have been created and even then it may take several seconds before anything happens

Again, CPU use remains at 100% while the scene is frozen. The library calls show up once qmlscene gets back to running the animation.

It may be that an event or timer queue fills up and keeps expired and/or processed entities around. Monitoring qmlscene with "top" hints at something like this as well: with the animation scene running, qmlscene process's memory use slowly grows. I observed a rate of little less than 1MB/minute on ARM.

This behaviour occurs independent of how Qt has been built: from single tree or in modular packages, cross-built or natively built. They all behave the same.

NOTE: (Simple) scenes without any animations do not exhibit this behaviour. We haven't tested with complex, non-animated scenes.

If there is any other information I can provide you with, just ask.