Bug 474567

Summary: Playback very slow and choppy due to follow playhead behavior, poor timeline redraw performance
Product: [Applications] kdenlive Reporter: jackleberry
Component: Monitors & PlaybackAssignee: Jean-Baptiste Mardelle <jb>
Status: CONFIRMED ---    
Severity: normal CC: fritzibaby
Priority: NOR    
Version First Reported In: 23.08.0   
Target Milestone: ---   
Platform: Debian unstable   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description jackleberry 2023-09-15 17:57:30 UTC 
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
Comment 1 jackleberry 2023-09-19 16:50:32 UTC 
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.
Comment 2 emohr 2024-05-29 16:07:44 UTC 
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.
Comment 3 emohr 2024-05-29 16:12:44 UTC 
Similar to Bug 475205