What is your Shotcut version (see Help > About Shotcut)? Is it 32-bit?
64Bit, 21.03.21
Can you repeat the problem? If so, what are the steps?
Add some of video track, then move one clip to another track
i often edit a videos for school which need for like 20 students or more, and everytime i move a sliced clip, it always delayed for 6 up to 7 seconds. I tried on Desktop (Ryzen 5 3600 (16Threads), 16GB, GTX1660 Super, SSD 512) and Notebook (Ryzen 3 2200G, 4GB, Vega 8 (onboard APU), SSD256) and both are the same. i also tried turn on Pararel Processing and HW Acceleration ON. still no luck.
i dont know whether this if this is intended to be like this, or this is a bug on thread managements? or i just missed some steps?
@shotcut, I read the thread that you linked to and you said a possible solution without doing a total rewrite of the timeline is:
when you drag a clip you will no longer see its image moving under the cursor. Instead you will only see a red outline similar to what you see for the other clips when dragging multiple clips. I am sure someone will complain about that degradation of the user experience.
If done how much of the timeline performance would this improve? Because if your only concern is that some may complain over that change I would say that no one will since the behavior you are describing is basically what many if not most video editors especially proprietary ones do like so:
So how far would the improvements in timeline performance go by making that modification?
I’m wondering if there is any chance to do sth with this performance issue. It is pending since many months and it’s still quite irritating. Sometimes I’m even wondering if to change video editing program for other just because of this… I like shortcut a lot and I know it better and better after many months of using, but waiting for moving clip makes me crazy… Games are capable to render ex. 60 fps full video style images and here just moving one small rectangle takes so much time.
I’m also wondering why copy/paste operation is immediate, while dragging takes ages. However it cannot be replaced one with another, as copy/paste causes other clips on the same track to be moved right. However I can’t understand why there is such a high time difference.
@shotcut what exactly is redrawing? all tracks? or only those two source and destination? perhaps there is some simple trick at least to reduce this overhead…?
I might help in bug testing but would prefer not to go into source code…
I’m wondering if improving this one small thing seems to be quite complicated? I mean to redraw only source and destination tracks and not all… How do you think? It’s probably easy to detect which two tracks should be redrawn…
In theory, yes. In reality, no. Everything is linked in a roundabout way, and every movement has potential to change the duration of the overall project.
The way it is currently implemented also requires each track that was visited to be redrawn as well. I worked on rewriting the UI for moving clips about a month ago but could not get it working. Maybe another attempt I will in the future when motivated, but there might also be a more comprehensive rewrite of the timeline UI.
I keep my fingers crossed for this another attempt.
One thing more comes to my mind. Probably you use different libraries. I’m not 100% sure but it looks like that for this redrawing only one thread is used (only one processor core). At least it’s my impression basing on observing performance monitor and also basing on that I can do in the meantime other activities ex. to surf over Internet without any delays. Perhaps there is some switch in one of “drawing libraries” which allows parallel redrawing. Either perhaps it’s worth to check if it’s possible to create as many threads as many tracks we have and to redraw each track in different track. Then in case of processors having many cores/threads it would improve “waiting time” a lot. Sure I don’t know the system too much but at first glance (it might happen I am wrong) each track can be redrawn independently…
