-
Notifications
You must be signed in to change notification settings - Fork 1.1k
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extending last clip in timeline is extremely slow. #294
Comments
Could you be more specific? What happens when you say it gets buggy? Attempting to reproduce this for myself just makes it more difficult to work with. I wouldn't know when or if it becomes buggy because I don't know what I should be looking for. As for your questions and suggestions, I don't think it would be my place to answer them directly, but I could pass them along for you. |
Thank you for your feedback, but "it gets buggy" is not a valid bug report. |
|
Thanks for reply and sorry for being short, but I though that just trying to reproduce it you were able to see it. Here's what's happens to me, https://dl.dropboxusercontent.com/u/30076751/shotcut--extend-timeline-bug.mp4 |
That link gives a 404 error, and this is the Shotcut project, which is not the same as OpenShot. |
yes, I confused the name, fixed it, and pasted the previous clipboard. |
Ok, I see it now. On my Windows and OS X systems, this operation is smooth and fast. On my Linux system, which is no modest PC and runs Linux on bare metal including OpenGL on the GPU (OpenGL is used for Timeline UI), I also experience this slow behavior. However, we use a high level UI technology for drawing the Timeline (Qt Quick), which puts many things outside of our control. We do not make OS-specific code for this, and it seems to be something specific to Linux. I am willing to re-open this as a Linux-specific problem, but it might not get much attention. :-S |
I understand! Thanks for the feedback |
A workaround is to copy the clip to the Source player, switch to the Source player, adjust the out point there (using the play back controls and 'O' keyboard shortcut is more convenient than dragging the trim controls), and then overwrite the last clip on the correct track of the timeline. |
That's fine. When I copy the clip to the Source, it's the full video again but in/out range selected. I can edit and move it to the timeline again. Is there any shortcut or control to step by keyframe instead of frame (as in Avidemux)?, that would be nice! (if it's rather easy to implement) |
Reproduced and had a look in gdb; think I see what's happening.
So for every modification, TimelineDock::clearSelectionIfInvalid is called which calls TimelineDock::setSelection. setSelection previously had an early return for when the selection is the same as before, but this guard was removed in cbc0ddd. Then there's how the selected signal will always call FilterController::setProducer, which calls MetadataModel::setIsClipProducer, which resets the entire metadatamodel, leading to lots of work for the view classes. I think the linux platform implementation for mouse event handling stacks up the mouse events while the windows/os X don't (I've seen similar issues on other qt based projects), explaining why you couldn't see it on non-linux platforms. |
I have the same Issue on Debian. If it can help for debbuging, extending a clip in the timeline becomes a little bit faster when I disable snapping. |
Still not fixed in 160901. Or may be fixed but obviously incompletely. Now if I drag the right edge of a clip it's being dragged reasonably quickly but always quickly gets out of sync with the real cursor position. Which is not much better than freezing. |
@ddennedy I tried two fixes here; both fix the problem by breaking the problemsome call chain, but at different places. One is to just keep TimelineDock::clearSelectionIfInvalid from calling setSelection at all when not needed:
But this feels a bit wrong, as it should ideally be up to TimelineDock::setSelection to figure out if changes are needed or not. Like I mentioned earlier, setSelection had a check for this before, and bringing it back, like this:
...also fixes it, but then (if I read the cbc0ddd history right) it might affect a crash with properties changed on the last clip. I wasn't able to reproduce the crash after my fix, but I don't have exact reproduction steps... How should I proceed? |
Thanks @metellius |
great news 👍 |
The issue needs to be reopened because the workaround posted by Metellius seems to be very far from perfect. Here is the video of how it works on my machine (Debian Stretch/AMD64/Radeon R7): https://vid.me/8nSW |
I think what you're seeing is an unrelated issue that was not visible previously due to the slowness. |
@Efenstor The issue as reported is indeed repaired. Your video just seems to be showing that timeline trimming, in general, is still not great behavior. No need to open a bug for that as I do not generally accept improvement requests as bugs. This tracker is for harder defects. Yes, we will try to improve its behavior over time. |
It's fine. It's quite enough to know that the problem is acknowledged. :) |
First of all, this app is great! a miracle in Linux.
Say you import a long length video, it's difficult to set an start/end point in the Source preview, so I choose an approx range and move it to the Timeline to zoom in.
When extending any of the (start/end) extremes far away from what I've previously chosen it gets buggy.
Sorry but I couldn't make an account in the forum to disscuss these,
The text was updated successfully, but these errors were encountered: