Blender UI Locks

Feature & Design Feedback
1

When running jobs in a background thread (e.g. baking), we usually have lock the user interface to avoid race conditions when the UI is drawn or is interacted with.

The way we do this right now is not ideal for two main reasons:

  • There are multiple flags which control this locking and it’s often unclear what they do exactly. In practice some code just uses all of the the flags just to be sure. There are ARegionType::do_lock, WindowManagerRuntime::is_interface_locked and G.is_rendering (which is often used by baking code too).
  • Taking the locking into account is opt-in. This leads to code having race conditions that are very hard to find. The drawing code of some editors may be thread-safe in vanilla Blender, but is not if there are additional panels defined in Python.

I don’t have the final solution yet, but it would be great if we could achieve the following:

  1. Have a more well defined set of UI locks with clear definitions of what they mean and imply.
  2. Be more explicit about what drawing code is allowed to run while some background job modifies data. We need to be especially careful with all places that may allow Python code.

Might also be worth investigating communicating between the background job and UI/main thread so that the background job can tell the UI thread when it’s safe to redraw and then waits until the redraw is done before continuing.

Before I can continue figuring out what the right solution is, I need some feedback: What is the user expected to be allowed to see and do while baking and while rendering?

For context, I was looking into this because incomplete locking seems to be the cause for #132941 - Regression: Geometry Nodes: At some point the Point Cloud simulation disappears - blender - Blender Projects.

5 Likes
2

From my experience rendering shots, I almost always need to enable “Render > Lock Interface” to avoid random crashes during renders (usually Eevee + motion blur + complex modifier setups on characters). So changes in how render locks work would affect my workflow.

While rendering:

  • I don’t care about the 3d views, neither interacting nor updating.
  • I must still be able to see the most recent rendered frame in the temporary image editor that pops up!
  • It would be great to still allow zooming and panning said preview (it is not a deal breaker if it’s not fully interactive until the next frame, since that’s the status quo of render locks).
  • If I had a free wish, I’d allow to scroll and pan some other 2d editors as readonly, to allow double checking render settings, viewing the timeline, etc. But that would likely be too complicated to implement?

I don’t bake very frequently so I have no strong opinions there. I also don’t use any add-ons that have custom drawn overlays.

4 Likes
3

What is the user expected to be allowed to see and do while baking and while rendering?

I am not sure this is the actual question we should be asking.

Ideally Blender UI is never locked. In an ideal world there might be a slight hiccup before a heavy operations begins to decouple things from the UI thread, but after that we should strive for the UI being responsive, and the background job operating on a local copy of data.

This entire Locked UI thing was just the easiest way to circumvent some legacy nature of Blender not designed thread-safe from the get-go.

6 Likes