Hello,
With a very powerful PC, timeline editing performance is not an issue (especially with proxies and preview scaling) however there is one area where ShotCut still has issues: timeline zoom.
Zooming the timeline seems weirdly slow and it seems to get slower the higher the desired zoom. I would be interested in why that is on a technical level, perhaps I could try to contribute some optimizations on GitHub.
Besides, adjusting timeline zoom with the GUI slider takes about a second, but at least it is a one-shot operation. When using the scroll wheel however, it appears that several successive zoom changes are triggered one after the other (though it does look like there is some “grouping” of wheel events) which causes the transition to be very choppy and happen “in-stages”, and take about 3 seconds, which really makes it hard to do precise editing in my opinion.
I’m wondering if there are ways to mitigate the problem and I would like to start an open discussion on how the issue could be resolved, as I think addressing this aspect would massively improve usability for all users. Again I would be willing to personally contribute code.
We chose to implement the timeline in QML/javascript - which has some maintainability advantages. But maybe there is a performance overhead.
Waveforms might be a factor. And maybe thumbnails. But I think it is mostly the overhead of traversing the model and redrawing each clip.
If you are a programmer, you can actually do some editing by just extracting the portable zip and modifying QML files. If you need to edit C++ code, however, you would need to put together a whole development environment.
Ok Interesting, thanks. I wouldn’t call myself a programmer but I do occasionally contribute to large open source c/c++ projects. I’ll take a look at the javascript, though it might be that this operation needs to be implemented in c++ to get an actual performance boost.
I understand the choice of javascript for code workability issues. On the other hand, as you say, it is to the detriment of performance. An unsustainable long term strategy, in my opinion.
It is not implemented in JavaScript or QML alone. There is a lot of C++ code underlying these. QML composes C++ objects, and JavaScript is used lightly for expressions and short code snippets. You might want to learn a little more about these before making claims that simply rewriting it in another language will fix it.
Today, I checked this out using the visual QML Profiler in Qt Creator. It is new to me, and it was fun figuring out how to use it to formulate insights. I found there was some redundant work due to signal (event) cycles, and that much time is spent in the time ruler along the top of the timeline. So, I had to break cycles, collapse repetitive signals, and decouple the ruler update from the tracks. While it is better, it is still not fluid on anything but small projects.
Another idea is to make a proxy or display model that sits between the data model and the QML view. This new model would contain only the subset of data that is currently in the viewport of the timeline based on zoom and scroll. However, this gets complicated quickly and is a big project just to handle the display side of it. Then, to handle the interactivity may be more difficult. Just to get started thinking through this, try to imagine how to make the horizontal scroll bar work with some clips starting before the left edge and clips on other tracks that start after. And that is just one aspect of this. Once all of this is done, how confident are you that the thicket of code (and bugs) created to make this all work will actually perform better? Consider all that must be coordinated to scroll the timeline. And when you zoom out enough, basically this proxy model will represent all or most of the data anyway. I think this approach may only be sensible when there is no zoom and limited interactivity.
New to the forum, just responding to a few things while I prepare to write my own comment if it’s not already reported elsewhere. Yep, I have this issue too… it is quite choppy to zoom in and out of the timeline - either with CTRL + mouse scroll wheel, dragging in the zoom tool or clicking + or -. All methods produce the same choppy experience. I have a decent Windows PC, though not brand new. Would be awesome if this code idea improved performance down the line.
Thanks for looking at this aspect. It’s interesting.
In fact, the fact that the timeline is difficult to manipulate from a certain quantity of data is not a problem.
If and only if, as shotcut users, we know its limitations. Because there is nothing more frustrating than being stuck on a project.
Optimizing the timeline should not come at the expense of shotcut’s ease of use or opening up other limitations.
Therefore, communication on actions and elements blocking the timeline is essential. And therefore the way to circumvent the problem (such as the use of a master // open mlt…) and the optimization of the means of circumvention.
I prefer new features to haphazard developments that could lead to dead ends.
Let’s start with the idea of a possible improvement in timeline performance for large projects (and we need to define what large project means) but in the long term without calling into question the foundations of shotcut.
But firstly, rely on other performances, such as chaptering (MLT master) and the appropriate tools (the master should not be an addition of MLT or something efficient; because at the moment, opening a master’s degree is a challenge on large projects.
I don’t know if my words are clear… And I’m not a developer… but I have (a little) knowledge of data structuring.
And for the zoom (which is one aspect of the timeline), would it be possible to have a numerical value associated with the zoom, on the one hand an absolute value (regardless of the length of the video) and on the other share a relative value (depending on the length of the video)?
Yes I know nothing about these things, so let me rephrase: if fixing the issue were as easy as changing a few lines of javsascript it would have been fixed already. Without any context, this looks like an issue that needs intervention at a deeper level, c++ or whatever other language/layer.