openshot-qt
openshot-qt copied to clipboard
OpenShot
Ruler isn't fully drawn if timeline length exceeds maximum canvas pixel dimension (32767px)
System Details:
- Operating System / Distro: Fedora 25
- OpenShot Version: OpenShot-v2.3.1-x86_64.AppImage
Issue Description and steps to reproduce: I have a ~35 minute long project and I noticed that the time scale disappears from the top of the timeline under certain conditions:
6sec zoom: time scale disappears after about 32m45s (1965s = 6 x 327s) 5sec zoom: time scale disappears after about 27m17s (1637s = 5 x 327s) 4sec zoom: time scale disappears after about 21m50s (1310s = 4 x 327s) 3sec zoom: time scale disappears after about 16m22s (982s = 3 x 327s) 2sec zoom: time scale disappears after about 10m55s (655s = 2 x 327s) 1sec zoom: time scale disappears after about 5m27s (327s)
It looks like there may be 200 "points" used to display the time scale. 327 seconds would place the "points" from 0 to 65400. If these points are determined by a 16 bit integer variable, that variable would overflow at 327.675s with a 1s zoom.
I haven't had chance to look at the code, but the solution may be to use a 32 bit integer to store the points.
Let me know if you want any screenshots or additional info.
Thanks!
-Rich
@N3WWN - Thanks for you feedback. I will take a look at this. Please do provide some screenshots.
@DylanC
No problem at all! I'd love to be able to contribute to the project, but not sure where I could begin. Do you have a design document that will let me get my head around what the software is doing, all the moving parts (or at least some of them), etc so I can do more than just report issues?
As requested, attached are screenshots showing the issue I'm reporting.
I downloaded a royalty-free video and just placed it on the timeline a bunch of times to get the video length necessary.
1sec zoom: time scale disappears after about 5m27s (327s):
2sec zoom: time scale disappears after about 10m55s (655s = 2 x 327s):
3sec zoom: time scale disappears after about 16m22s (982s = 3 x 327s):
4sec zoom: time scale disappears after about 21m50s (1310s = 4 x 327s):
5sec zoom: time scale disappears after about 27m17s (1637s = 5 x 327s):
6sec zoom: time scale disappears after about 32m45s (1965s = 6 x 327s):
These were captured with a fresh download of OpenShot-v2.4.0-x86_64.AppImage on the same Fedora 25 system where I first noticed the problem.
Let me know if I can provide any further information or if there is any way that I can get up to speed to contribute directly.
Thanks!
@N3WWN - Thanks, this is great and a very strange bug too. The best way to get started is to email Jonathan about contributing. He should be able to answer all your questions. We could definitely do with some extra help. Even if you can just help test some issues and report back on them.
I would help with the development too but I don't know Python at all.
@DylanC , I can confirm that this bug is still present after #1411 . The zoom values are different (no 6sec zoom, for instance), but the results are the same.
Here's the ~10m55s timeline disappearance for the 2sec zoom level:
Any chance of getting a "BUG" tag on this one? When I've been looking for things to work on (as time permits), I usually search for that tag.
Heh. You know, in all my testing of the zoom code, and even zooming out far enough to discover the 24-hour rollover bug (where the ruler markings goes a little crazy if the visible ruler length is > 24 hours, not that there's any reason it should support that), I never noticed this.
I'll try to see what I can see, too, though I'm worried that this bug may be a bounding-box/widget-sizing issue somewhere in the Angular code. Viewing src/timeline/index.html in Chrome is even more broken (it always ends the entire timeline at 5 minutes, even when there are clips positioned past that point).
Want to hear something hilarious?
This exact bug was present as far back as OpenShot 1.3.0, reported in Launchpad on 2011-02-20.
The timeline only shows the first (320*zoom seeting) seconds of a project. So if the zoom slider setting is set to 1 s, the timeline stops at 5'20'' (=320'') if it set to 2 s, it stops at 10'40'' (=640''), 4 s it stops at 21'20'' (=1280''), etc.
It somehow survived the complete 2.0 redesign to continue biting us in the ass 7 years later. That is one persistent-ass defect! :rofl:
@mikelacsa
Very much so. Steps to test/reproduce:
- Import a long video file into OpenShot (I used a 76-minute movie.)
- Add it to the timeline
- Select the clip and use Next Marker to jump to the right edge
At 10-second zoom, the ruler markings peter out at 00:54:35:01, which exactly fits with @N3WWN's observed multiples-of-327 pattern. (54m35s = 3275 seconds; the last visible label marker is at 54m30s which is 3270s.)
So, I looked into this some more. By adding a ton of logging to ruler.js temporarily, I was able to determine that the drawing function computes all of the correct values for the ruler parameters, goes through every iteration necessary in the loop that draws the tick marks, and computes the correct time index for every tick necessary for it to draw the full length of the ruler.
If I have that 76-minute movie I mentioned placed on the timeline, and I zoom out to 10 seconds, the initial computations produce:
timeline_webview:INFO Computed timeline width in pixels: 46294 (based on duration: 4629.4)
timeline_webview:INFO Actual size of track container: 46294
timeline_webview:INFO Defining ruler parameters, tick_pixels: 100 each_tick: 50
timeline_webview:INFO Redrawing ruler, num_ticks: 925.88
and the redraw loop logs all the way up to:
timeline_webview:INFO Fill text for tick 926: 01:17:10
timeline_webview:INFO Last tick drawn: 927
Nevertheless, the ruler stops at 00:54:35, which is tick 655. Anything after that is still computed, it still goes through all the motions, but nothing gets drawn.
Then I got to thinking. The ruler is drawn on a <canvas> element, which even though it seems simple is actually a hardware-accelerated (potentially) rendering surface, right? So, there's probably some kind of constraint on just how huge those can be, right?
*google*, *google* (OK, in reality it took me literally 5 seconds of googling, I typed in "webkit canvas maximum size" and looked at the very first hit. Didn't even need to click on it.)
For Google Chrome, the maximum allowable width and height are 32,767 pixels
"timeline_webview:INFO Computed timeline width in pixels: 46294 (based on duration: 4629.4)"
"Computed timeline width in pixels: 46294"
"maximum allowable width and height are 32,767 pixels"
(I also attempted to confirm my theory by turning on audio waveform display on my 76-minute timeline clip, since other than the ruler and the cache progress readout, clip waveforms are the only other <canvas> element on the timeline.
...That was 14 minutes ago, and my mouse pointer is still a wait-spinner. I don't think it's coming back.)
But I'm sure I'm right, because remember @N3WWN's computations regarding the ruler constraints. Turns out, it's not multiples of 327 seconds that are the issue, but multiples of 327 * 100 pixels/tick.
The fix for this will be to construct the ruler as a series of canvas elements, laid end-to-end-to-end in the ruler container, rather than creating one giant canvas element. There's no reason at all that it needs to be one huge canvas.
...Rendering my video's 46,000px-wide audio waveform, well, that's a bit trickier.
The ruler-drawing changes (to use multiple canvas elements, if necessary) would actually be a pretty simple fix, so I've labeled this as a newcomer issue.
Thanks for re-opening this issue. I just verified that it is still a problem with a recent v2.4.4-dev2 daily build. :)
Thanks for re-opening this issue. I just verified that it is still a problem with a recent v2.4.4-dev2 daily build. :)
Well, yeah, I know I certainly haven't fixed it. You saw my explanation above for why it's happening, though, right? At least now we know that much, I guess. Doesn't exactly fix anything, of course...
Any news about this problem? I'm trying to make a video that is about an hour long, and the fact that I'm not able to zoom too much because otherwise the ruler disappear, it create to me a lot of problems. Anyway thanks so much for your work.
I can confirm this bug with Ubuntu 18.04 64b and latest ppa release 2.5.1
I don't want to put any pressure on the developer who I thank very much for his excellent work, but I'm curious to know if there is any prediction if this correction will be made and if so, in what timeframe. Thanks
same here
On Mon, Jun 29, 2020 at 9:12 PM Eate [email protected] wrote:
Reproduced with Ubuntu 20.04 amd64, version 2.5.1 (via stable PPA).
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenShot/openshot-qt/issues/652#issuecomment-651477043, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIFQYLAQDNR4OGIHNHCVMTLRZFCZ3ANCNFSM4DLYEQIQ .
Thank you so much for submitting an issue to help improve OpenShot Video Editor. We are sorry about this, but this particular issue has gone unnoticed for quite some time. To help keep the OpenShot GitHub Issue Tracker organized and focused, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.
This issue will be closed, as it meets the following criteria:
- No activity in the past 180 days
- No one is assigned to this issue
We'd like to ask you to help us out and determine whether this issue should be reopened.
- If this issue is reporting a bug, please can you attempt to reproduce on the latest daily build to help us to understand whether the bug still needs our attention.
- If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.
Thanks again for your help!
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
Thank you so much for submitting an issue to help improve OpenShot Video Editor. We are sorry about this, but this particular issue has gone unnoticed for quite some time. To help keep the OpenShot GitHub Issue Tracker organized and focused, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.
This issue will be closed, as it meets the following criteria:
- No activity in the past 180 days
- No one is assigned to this issue
We'd like to ask you to help us out and determine whether this issue should be reopened.
- If this issue is reporting a bug, please can you attempt to reproduce on the latest daily build to help us to understand whether the bug still needs our attention.
- If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.
Thanks again for your help!
I was hoping this was resolved with the updates to the timeline/zoom code that we've seen in the recent dailies, but it is still an issue with the newest daily (OpenShot-v2.5.1-dev3-daily-7635-d9ea98eb-92ff6084-x86_64.dmg):
I can no longer tell what zoom level is currently displayed, but you can see that somewhere around 20m33s, the timeline stops displaying.
The latest updates also mean I can now get the playhead to detach from itself:
So that fun ;)
@N3WWN Thanks for your examples. I've got a PR in review about this.
I think I need to account for some more changes in the zoom slider.
@Dipanshu-Kubde Are you having issues with the ruler not fully drawing? I believe that has been fixed. We have made significant changes to how the ruler is drawn in the most recent stable release.
Hello, I don't know if I should create a new thread for this bug. It is related to the timeline lost of zoom in capability. The bug I would like to report is for whatever reason (mistake or change in the project) we have to enter a lenghty element, then play with the zoom out button and then shorten the element again, then we lost the timeline zoom in capability. In this video example at the end I am stuck with a timeline with minute precision.
https://user-images.githubusercontent.com/77164855/141560890-1d428a2f-f9cb-407c-b18f-e95d0d9ebdcb.mp4
.
.
@rem747 For that particular issue, I'd recommend you use the +/- keys to zoom in and out.
I can also start working on making sure the zoom slider adjusts to the maximum length of the project
@rem747 Ctrl+ scrollwheel should also allow you to scroll beyond limits for mouse controlls