https://bugs.kde.org/show_bug.cgi?id=474567
--- Comment #1 from jacklebe...@yahoo.com --- 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. -- You are receiving this mail because: You are watching all bug changes.