Thanks so much for quickly addressing the “forced” incremental zoom updates when dragging the zoom slider…
The problem is… it’s still too slow to be usable for 90 minute show.
We have a very powerful editing computer and dragging the timeline from one end to the other takes 10 minutes to update… There’s no way folks can wait that long for one zoom.
I suspect the incremental timeline updates are still happening behind the scenes (i.e. even though the slider does not “force” the user to tick through each incremental zoom update, it’s still calculating all those incremental “zooms” when the user settles on a spot. My theory is the code still does all the incremental timeline updates behind the scenes, based on the fact the time to zoom has remained unchanged. Before we had to tick through the 10 minutes of zooming. Now we can drag freely, but pay the 10 minute penalty all at once. Ouch!
If my theory is wrong, is the code doing something exotic while repainting the zoom? Like unnecessarily moving things around in memory, like HD files? The timeline updates should be simply managing metadata and repainting the UI. On other editing systems the timeline zoom is lightning fast, so perhaps there’s a memory leak, or unnecessary call.
Happy to help test with my 90 min shows, if you guys want to send me a test build.
Love the product, really pushing others to use it. Just a few ankle biters
Shotcut plays and Exports using multiple threads but Zoom the Timeline or rebuild audio waveform on an extended Timeline has always been slow because it is not multi-threaded.
Yes, I just spent the time to export 2 source clips .m2t (mpeg-2 HDV anamorphic) to “intermediate/ProRes” (mpeg-2 Full HD) and imported the new .mov files into a new project which results in a 70 minute Timeline. Zooming just one click plus or minus can sometimes take over 2 minutes. Viewing a System Resource Monitor I see only one of my four cpu cores maxed-out during this time and the Shotcut interface is unresponsive. I thought by using an “editing codec” rather than a “transport stream” codec would mitigate the problem but it has not proven to be so. -=Ken=-
I spent some time on this today working with a 63 minute clip. Believe it or not, the main problem is redrawing the ruler above the timeline. Of course, redrawing waveforms does not help, but the only simple changes there are a couple of places to prevent updates if it is disabled. Also, I can make it so that muted tracks do not show the waveform. A simple change to the ruler makes it so that ticks and timecodes are spread further apart as you zoom in instead of adding many more of them as it does today. However, I might also try to rewrite that part of the code. Either way, there will be improvements in the next version even if there are some sacrifices.
Thanks for looking into this Dan. Shotcut is such a good editor, and very enjoyable for shorter projects. Is there any way to make that function multi-threaded? I’m not a programmer but I have just enough awareness of the inner workings to ask.
Here are some tests results after today’s changes with a 63 minute clip whose audio levels were already generated and stored in the database. From a clean start, I open the clip, add it to the timeline by itself, drag the zoom slider completely to the right, and start the timer when I release the mouse button:
waveforms | v17.11 | v17.12
----------+--------+--------
on | 36s | 6s
off | 30s | 1s
Test the changes in v17.12 and see what you think. Still too slow sometimes, I know. Please be aware that some sacrifices had to be made to the timeline “ruler” like the removal of some tick marks and spacing out the remaining ticks & timecode as you zoom in.
That’s a great improvement. Love it - can’t wait!