Nominate our 2022 Qt Champions!

Adding 2nd window causes animation stuttering in 1st window

  • With a single window open, my Qt Quick table view scrolls smoothly (auto-scrolling it via a flick()). If I spawn one more window (with nothing it it except a static Rectangle) then the animation on the table view jerks noticeably every few frames. If I close the 2nd window, everything is smooth again. This happens with threaded or basic render loop, fixed or vsync timestep, vsync on or off.

    It's definitely not an issue with being CPU or GPU-bound. I think the above suggests there must be a fairly straightforward error in the way the animation loop or event loop is being handled when multiple windows are open. Indeed, note code comment below in src\quick\scenegraph\qsgthreadedrenderloop.cpp

    The way the render loop is handled changes when there is more than one window. I haven't found the root problem yet, but I do see several places where the code forces the update interval from a float to an int, so e.g. 16.666 becomes 16. My current theory is that somewhere this error is accumulating so that every so often an animation frame is either skipped or updated with twice the normal delta or something along these lines.


    qt.scenegraph.general: Using QRhi with backend D3D11
      Graphics API debug/validation layers: 0
      QRhi profiling and debug markers: 0
      Shader/pipeline cache collection: 0
    qt.scenegraph.general: threaded render loop
    qt.scenegraph.general: Using sg animation driver
    qt.scenegraph.general: Animation Driver: using vsync: 16.67 ms

    Qt 6.1.0 on Windows 10 with Qt Quick.

    I've commented in as it seems like it could be related to that issue.

    For this project its a strict requirement that there be no visible stuttering whatsoever.

  • I think I've confirmed this must be a bug in Qt. I have reproduced it using the animation example ("Qt Quick Examples - Animation", Qt\Examples\Qt-6.1.0\quick\animation)


    1. Modify sample to create two QQuickViews, run and position side by side.
    2. Observe stuttering animation of "TV Tennis" example.
    3. Minimise one window (this triggers "*** Stopping non-render thread animation timer").
    4. Observe smooth animation.

    Same result if at step (3) you close one window.

    I added some timing inside the non-render thread timer. This may point to the root problem: every 20 frames or so, the timer gets called with a much shorter interval than what was requested. But the animation system still gets passed a delta of ~16ms.

    So in the space of 16688us + 5863us = ~23ms, the animation system has been told to advance 34ms.

    This error is probably what is causing the stuttering. If anyone who has worked on the animation timing part of Qt could chime in that would be great. I'd love to fix this and submit a pull request.

    qt.scenegraph.renderloop.ex: - ticking non-render thread timer, interval: 16688us
    	updateAnimationTimers, delta: 17ms
    qt.scenegraph.renderloop.ex: - ticking non-render thread timer, interval: 5863us   <---- Outlier
    	updateAnimationTimers, delta: 17ms
    qt.scenegraph.renderloop.ex: - ticking non-render thread timer, interval: 15959us
    	updateAnimationTimers, delta: 16ms

    Also everything is rounded to integer milliseonds. The difference between 16.666ms (60Hz) and 16ms is ~4% error right there, definitely visible. And the difference between 16ms and 17ms (often the gap due to the integer representation) is ~6% error frame to frame. I'm not sure why floats aren't used throughout, integer milliseconds is simply not enough temporal granularity to have smooth animations, the human eye is too good.


  • Banned

    This post is deleted!

  • @Jarrod It seems like I'm having the same issue. When running a Qt application with a single window the performance is good, running at 60 FPS. However, when adding a secondary window (actually a duplicate) the performance starts to drop. Performance continues to drop when adding more and more windows, while still not fully using available CPU power (approx. 160% out of 400%).

    Did you manage to find a solution or workaround for your issues?

Log in to reply