SUMMARY Unless totally zoomed out, playback will become slow and choppy due to the timeline viewport following the playhead (which is very slow to redraw). Although there is an option that sounds like it affects this following behavior, that option doesn't appear to work. Although sometimes (randomly) the viewport does not follow the playhead, I've found no way to consistently enforce that behavior. This slowdown occurs even when the preview window is fullscreen, covering up the main window (I would have expected all drawing operations to be short-circuited when the window is not visible, but maybe this isn't an optimization QT is capable of doing?) The result of this is lots of (slow redrawing) zooming in and out in order to allow both fine-ediitng and relatively smooth playback. Drawing of the timeline in general seems unreasonably slow (when scrolling etc). It behaves as if it's drawing the entire timeline and only showing the part within the viewport, rather than optimizing by only redrawing the part that's visible. This is somewhat confirmed by audio waveforms extending beyond the clip end in a flash before being redrawn correctly. STEPS TO REPRODUCE 1. Have a big project 2. Zoom in 3. Start playback OBSERVED RESULT Slow and choppy EXPECTED RESULT Smooth. SOFTWARE/OS VERSIONS ADDITIONAL INFORMATION
Upon further testing with a smaller project, it is clear that either the drawing routines are unnecessarily rendering off screen content, or the processing of the scene graph is unreasonably slow. I'm assuming that kdenlive uses at least one QT widget per clip. This likely accounts for the excessive memory consumption and a large part of the slowness. It would require a significant rewrite, but a far more efficient way to do it is to either avoid using widgets entirely (just draw the clips etc. based on the already in-memory data-structure representing the open project) or only instantiate enough widgets to represent on-screen content (some pool of widgets could be kept instantiated and just have their coordinates updated to represent different clips). Doing this conceptually simple optimization can result in timeline drawing/scrolling performance that is independent of project size. As it is, kdenlive's usability is inversely proportional to the project duration/number of tracks+clips. Which is a shame because, aside from hitting the open file limit, the program seems to be stable at large project sizes, just not performant enough re UI interactivity.
Thanks for reporting. I can confirm. The more tracks have clips the slower is the playback (playback stuttering). If the timeline contains clips which doesn’t meet the project settings, playback is slow as well, specially from one clip to another. Reduce the preview resolution has no effect on playback speed.
Similar to Bug 475205