GNOME Bugzilla – Bug 575311
clips appear to be duplicated at high zoom levels when the timeline cursor is near the edge
Last modified: 2009-09-06 15:01:01 UTC
Place the timeline cursor near the end of a clip while zoomed out, and zoom in. The clip will appear to be duplicated after its endpoint (while in reality, it's not).
Created attachment 130622 [details] screenshot of the phenomenon
Don't really know what can be done to be honest. For most videos, neighbouring frames will look vastly similar (there's only a 30-40ms difference between them). Maybe we should limit ourselves to 1 frame out of 2 ? But then... how would you spot instantly where the first frame you want is ? Or what if it's a high-movement video and you actually do want to see all the frames ? I can't really see how this is a blocker, demoting it. Requires a bit more thinking.
I got completely confused between clips and frames. I can definitely reproduce this !
Created attachment 134571 [details] screencast demonstration Seems there was some confusion. This is about seeing duplicate clips at the end of the timeline when there isn't any.
This bug is really with scrolling. I have as yet to reproduce this bug on Jaunty, but I can do it reliably under Intrepid. Jaunty is using goocanvas 0.14. In any case, what actually seems to be happening is that the scroll position is allowed to exceed the maximum limits of the scroll adjustment. It's still not clear to me why this is happening, but it probably has to do with the auto-scrolling code which tries to center the scroll bar at the playhead. In this broken state, part of the canvas is not refreshed. In the initial state this looks like duplicate clips. What you're actually seeing are the old clips that have not been redrawn. If you damage that part of the canvas you'll see it smear, and this effect extends to the ruler as well. As soon as you click the scroll bar, the scroll position is clamped to the maximum value, and everything goes back to normal.
This seems fixed for me. Can someone else confirm ?
Yes, this seems fixed. May have caused bug #591617 though.