Not freezing the UI on long operations
We've all been there. We accidentally set the subdivision modifier too high, or added an extra '0' to something we didn't mean to and the program hangs, sometimes requiring a force close and in the worst case losing progress (daily reminder to save often!)
In modern day software this feels like something that shouldn't ever happen. Very few pieces of software now-a-days locks the UI, and I think in the next "big," revision of Blender, locking of the UI should be something that is seriously looked at.
The way I see it, there are 3 main things that need to be implemented
- Prevent locking of entire program UI . I haven't looked at Blender's source myself so I don't know if this is a multi-threading issue or not, but the entire program freezing up should be avoided if possible.
- Allow the developers to specify locking of specific viewports/parts of the program during certain operations. IE: Locking the 3D viewport during a complex boolean operation so that objects can't be moved and mess up the calculation. This should be minimal, but definitely something that might need to happen in some cases.
- Allow software interrupts during appropriate operations IE: You added too many subdivisions and it's going to take way to long to process. Since the modifier stack would still be unlocked, the user would be able to change the value to something more reasonable and have the already running operation interrupt itself, then start re-calculating with the new values.
8 Comments
Yes! This needs to happen asap. Being able to hit "Esc" and cancel every action should be a thing. Don't know how hard it is to implement but it would be very useful.
This proposal is very important, thanks (I'd post similar)!
Decoupling the UI and scene data from the rest would be great: one process for the UI itself, scene data is an another, if anything goes wrong there would be a button to restart the engine/background process, without losing the data/previous work : blender panic button
Even an automatic mode would be a safety measure: saturating the memory would trigger auto-restart of the engine and cancel the last operation.
It's always nice if there's some kind of indicator, a fuel bar, a clock, or something to indicate the difference between LOCKED UP and PROCESSING.
* @jeric_synergy * this as well. Sometimes things take so long I don't even know if I should just "Force Quit" or wait...
* @jeric_synergy * The only issue with that is to a computer "locked up," is the exact same thing as "processing," it's just processing something that will never finish.
* @Zach Hixson * , hopefully devs could find a metric that discriminates between the two. If a progress bar doesn't CHANGE, the user at least knows something was attempted, and can be given the option to abort.
It's when the user is left in the dark that should be avoided.
I have no problem with locking ui, but freezing without any progress or information that something really happen is quite big issue in Blender, especially when there is no way how to stop it.
This issue reaches down into details. It affects stuff like slide bars that redraws all the time and locks UI until they have computed. Being able to gracefully cancel operations should be able to solve these issues.