Performance issue when moving clips in or among video tracks

[Gizemquea]

Shotcut - Windows 10 - presumably all versions

Steps to reproduce:
1.) Create a project with several video tracks and so many clips that moving one doesn't seem "instantaneous" - even on a very fast machine this is not more than a few hundred (the project from issue #1029 may serve as an example)
2.) Drag an arbitrary clip from the timeline within its track and WITHOUT ever leaving said track - this is your normal operation speed for reference
3.) Drag the same clip but to another track - operation takes around 100 times longer (much longer than select, Ctrl+C, position playhead, Ctrl+B, Del of the original clip would take), at least several seconds
4.) Surprisingly this also happens if you just briefly leave the orignal track while dragging, even when releasing the clip on its original track but at a different position - the operation takes a very long time

[ddennedy]

When you move clips to new tracks it must reload the timeline when released. This is the same as choosing Reload (F5) in the timeline menu. There is no easy fix, and the timeline code must be nearly rewritten after figuring out another way to do this with the API.

[Gizemquea]

Well, at least the problem does not result in crashes/lost work etc. As annyoing as this is from the end user's point of view, it probably doesn't justify a major rewrite of the timeline code - and even if you consider doing this, then there are actually much bigger issues than that:
E.g. all keyboard shortcuts that trigger a seek operation (or any other slow operation for that matter) should really run in their own thread - this is already done correctly in the timeline if I use Alt+left/right to go to the previous/next edit.
But if a user presses "page down" three times in a row, he also expects to end up three seconds forward in the current clip - no matter how fast the machine can complete the individual seek operations. If the machine can't keep up, it should at least update the desired seek position independently and not block the input entirely until the current seek is done. This alone would probably save me about 1 hour working time per project (I use this >1000 times for each hour of video produced). I never reported this as a "bug" because technically it is just a design issue, but it really would be a big improvement...

[ddennedy]

I have thought about a possible fix without a rewrite, but 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.

[Gizemquea]

Thanks for even considering a fix. The issue is strongly depending on project size. In my usual projects this takes several seconds (and it is a reasonably fast machine) - I'd gladly take the red outline instead of the image just to get rid of the delay and I don't think there will be many people who'd rather wait that long just to have the clip image visible while dragging.
You could still make this an optional feature if you doubt this will be an improvement for all shotcut users.