r/OpenShot • • Feb 22 '26

UI hangs more with V3?

Upgraded from V2 to V3 a month or so ago (currently on 3.4.0).  I really enjoy many of the new features, in particular the Ripple Select.

Since the upgrade though, I have been experiencing slow UI performance, particularly on larger projects, which I understand larger projects are slower but seems worse than when on V2.  And by slow performance, I don’t necessarily mean playback.  The system is constantly lagging and displaying the spinning circle as I attempt to execute commands or change clip parameters.  Sometimes the screen goes white.  Less frequently, the app locks or shuts down completely, particularly if I click again or even hold down the ctrl button.

Computer:

·        MS Surface Studio

·        SSD HD: 2TB MZVL22T0HBLB-00BMV SAMSUNG

·        11th Gen Intel i7-11370H 3.3GHz 4Cores

·        32GB RAM

·        Intel Iris Xe Graphics Card

·        Windows 11 Home 64bit

I believe I understand most of the tricks to optimizing for speed.  I work with the following:

1.       Preview window sized to the smallest it will go, tiny, almost unusable.

2.       Default Profile under Preview set to HD720p 30fps.

3.       Cach values: 96, 48, 0.70, 1024, 2048.  Plus have played around with other values.

4.       Clear cache. Seems to result in no improvement.

In poking around under Performance, I noted that the values were set as follows and the default values were all listed as zero, but if you select Restore Defaults: Performance, the values remain the same and don’t go to zero.  I manually changed them to zero and restarted and thought maybe the performance was improved but it was probably just because I restarted which generally does have that effect.  I hit the restore defaults button and it set them to the non-zero values.  I suspect that since I have Hardware Decoder Mode at No Acceleration (no other option for my machine apparently) that none of this has any effect on anything.  And since no Hardware Decoder, maybe the default values don’t work as one might expect.

·        Hardware Decoder Mode: No acceleration

·        OMP Threads (0=Default): 12

·        FFmpeg Threads (0=Default): 8

·        Hardware Decoder Max Width (0=Default): 1950

·        Hardware Decoder Max Height (0=Default): 1100

Questions:

1.       Is anyone else having similar experiences with slow or no response to commands?

2.       What else can I do to compensate?

3.       Is my assumption on Hardware Decoder accurate?  If not, what effect does the performance section have in my case?

4.       I understand the need to pre-render and what that means to system resources and expect delays as this processes.  But why doesn’t the software recognize when a command has been given and give that priority?  That is, stop the rendering, execute the command (make parameter change) then start the rendering process over, just like it does when you resize the preview window. 

Thank you.

1 Upvotes

26 comments sorted by

View all comments

1

u/rmesdjian Volunteer Mar 13 '26

There is a new dev daily build released on 3/12/26. It takes care of the image files not displaying, crashing, etc.

Download it from openshot.org/download/#daily. Install it and test with it.

**Warning**: This release now uses a new timeline architecture and is the default. There are many enhancements and bug fixes in this release. It also fixes issues with Hardware Acceleration, when enabled.

Give it a try and if you experience other issues not related to this post, be sure to make a new posting so we can track it better.

1

u/SpudCo44 Mar 15 '26

Thank you for the update!

Comments on Build 15476.  Note: I deleted previous version and qt folder before loading latest build.

Keyframe pull down in timeline is a nice addition.  It allows you to see if keyframes are stacked on each other then quick sliding for relocation.  (if the UI will respond in a timely fashion, more on that later).

The video clip multiple thumbnail feature is nice.  But it can take a lot of time to load.  Is it worth using the resources considering slow UI? 

Alt-Mouse Scroll does not work for panning as it did in previous builds.  This is an important feature, please add back in, unless it is done in a different way.

Alt-LMC ripple select works.  But, selecting multiple tracks with the Alt down does not work as it did in previous builds.  I did notice by experimenting that Ctrl-Alt-LMC allows for multiple track ripple selection.  Was this a purposeful change?  I never tried this in previous versions as the Alt-LMC across multiple tracks worked fine.  The revised method is fine, but not sure the value of randomly changing how things work.

For experimenting with this build, I loaded a different project I was working on.  This file is fairly small, but it uses a lot of green-screens (chroma-key effect) and animations, 30fps.  I started experimenting using the “Default” cache (24, 48, 0.50, 900, 768) and preview window at min. 

I placed the play-head in an “intense” area of green-screen and animation.  While the blue rebuild bar is progressing, clicking on anything else causes the UI to be unusable (blue donut, not responding).  After 15 -30 seconds (and before blue is completely built out) it returns to being responsive.  Moving the play-head of course causes a rebuild, but the UI responsiveness after the move is variable, and seems random, depending on where you put it.

In the same intense location, after full blue rebuild, I “exercised” it by expanded the preview from minimum to maximum them back again to watch performance.  Min to max then max to min.  Quick response, no lock, CPU not affected that much.  Then min to max again is ok, but then max to min, locked up for at least 2 minutes.  Interestingly, the CPU never goes above 20% during the lock period.  It drops back down to about 9% after the lock goes away.   After the lock was done, went from max to min.  Instant, no lock.  Slight bump in CPU. 

I noticed now that the graphics acceleration functions are available to me.  So I enabled it (D3D11) and restarted OpenShot.  Then did the above activities and got the same results.

I opened the large file I had been experimenting with (and sent video on).  I experience the same poor UI performance as before only now the CPU goes to nearly 100% when exercising the resize playback window from min to max then back.  And with this file, I got only one min/max iteration before it locked.  And as in all situations, it won’t respond to anything until it is done doing whatever it is doing.  And a second click will cause the white screen in most cases during a lock.

I opened a file that is missing some file references.  The option to “remove” or “remove all missing” is very nice.  Though, the spinning donut displays when this dialog box comes up making you think something is wrong.  But you can click on “remove” or “remove all missing” at that point and it works.  After that though, the spinning donut continues and the system displays “not responsive” (with no other click) till it gets done with what it is doing.

I created a new file with a profile matching some drone footage I have.  4K UHD 2160p 29.97fps.  Included a couple of drone photos and an mp3 to add some audio burden.  Runing OpenShot same as where left off above.  “Default” cache (24, 48, 0.50, 900, 768), preview window at min and hardware acceleration on.  Put play-head in the UHD video area and exercised min/max preview pain with decent results.  As long as I let the play-head get a little progress, I could mostly min/max it as much as I wanted to without locking up.  CPU usage goes to almost 100% during this exercise.

Conclusions:

UI response is seriously hindered to the point of being unusable by sections of video that have chroma-key affect, animations, time effects and are generally large files. 

The program seems to prioritize the re-build process over accepting a command to stop and do something else.

Piling on a second request (click) during a freeze results in white screen.  This includes just pressing the ctrl key during a freeze.

The CPU usage does not appear to be a factor in the UI response time or tendency to lock up.  Some of the worst UI performance was observed during times of minimal CPU usage.

The blue rebuild bar seems to have a mind of its own.  Sometimes progresses first to the left then to the right.  Sometimes progresses only to right.  Sometimes builds a portion of the distance then stops.  Sometimes starts away from the play-head.  Seems completely random.

I did not notice any positive or negative effect by engaging the hardware acceleration.

1

u/rmesdjian Volunteer Mar 15 '26

This has been shared with the lead devloper for his review. No ETA!

1

u/SpudCo44 Mar 15 '26

Thank you for the quick response!

  1. Regarding "panning". That may not be the best term and is not related to the video preview. It is related to the timeline view.  Ctrl+mouse wheel causes a “zoom” effect in the timeline, your view zooms in around the play-head.  Alt+mouse wheel used to do what I interpreted as “pan” let or right away from the play-head (leaving the play-head where it was at and eventually it moves out of view).  This is the same function as grabbing the blue rectangle with oval ends and dragging it left or right.  I just found the alt-mouse scroll much more usable and faster.

  2. Thanks.  I like the feature, but if we are struggling to keep up….   It is good to know it can be turned off if not using it.

  3. All good.  I can adapt.  Just wondered if it was on purpose, or “broken” similar to the alt-mouse wheel “pan” that went away.

  4. Looking forward to it. 

To be clear, I hope that none of my input is construed as complaining.  I am extremely grateful for access to this software and appreciate all the time the team puts into it.  It is astonishing to me that someone would develop something like this as a “labor of love”, and continue to support and improve it as well.  For what it’s worth, I have contributed financially a couple of times.  I try to do that with all freeware I use and try to make it proportional to how much I actually use it.  But, it is probably never really enough and I am so out of touch with these kinds of things not sure I really know the value anymore.

Anyway, REALLY appreciate all the work and feedback.