Have a Qt Quick application
and
use the threaded render loop (not relevant for basic)
and
request updates continuously on an item or the Quick window
and
do this starting "early", e.g. have this FrameAnimation in the scene, with running set to true from the start (does not happen if running is set to true later):

        FrameAnimation {
            running: true
            onTriggered: root.update()
        }

Or call window->update() every time in a slot connected to the afterAnimating() signal of QQuickWindow.

These cause an unnecessary number of invokeMethod() calls queued up, generated in QWindowsWindow::requestUpdate() and it may never recover afterwards. (so we will continuously have an ever growing number of metacalls queued, even though 1 is perfectly enough, leading to very choppy rendering on screen, although the CPU/GPU load will be perfectly normal)

This is because the async invocation (invokeMethod, QueuedConnection) of deliverUpdateRequest() in QWindowsWindow::requestUpdate() in the callback on the vblank watcher thread is not guarded further, and will be issued every time the main atomic guard (m_vsyncUpdatePending) was 1, which will happen when requestUpdate() is called in the gui thread. If the events (metacalls) are not processed (for whatever reason) but requestUpdates are issued, then due to the multiple invokeMethod it ends up in a feedback loop kind of situation where there will continuously be more metacalls queued then we can process.

The implementation should rather guard so that invokeMethod is not called if it has been called already (on the vblank watcher thread) while the metacall event is not yet delievered on the gui thread.