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.

Reply via email to