UI performance is suffering due to a lack of thread priority
First of all, we all can agree that 3D software is very intensive and will eventually slow your workstation down when you have a dense scene loaded. The problem is that Blender does not seem to do any kind of active context switching for CPU thread priorities short of "rendering" and "not rendering". For example- lets say I have a modestly dense scene loaded- around half a million triangles or so with no materials or lights. It stands to reason that while you're interacting with geometry directly in edit mode that things will slow down a bit (or in blenders case, a LOT).
Now using that same example, say that you just want to load up user preferences and scroll through your keymaps to find something. good luck! navigating through the blender UI is extremely difficult and stuttery when a scene like this is loaded. the UI seems to be completely hitched to whatever scene you have loaded, even if it's just sitting in the background not doing anything. Input in my test scene has about a 500-1000ms delay. Input events in the scene itself seem to get missed- in this example I was actually in the keymaps to see why my double-press events weren't firing.
So this isn't really meant to be a whine post- but I felt like some context was needed.
The proposal is almost certainly not an easy one- but all the same, I think Blender would benefit from the UI and input system getting some kind of process priority. Blender has a lot of things to process, so I imagine it is tempting to throw every available ounce of processing power at the various tasks that need to be done, but if the user is not in control of the scene, all of those tasks are fairly pointless.
4 Comments
I think it is just beceause blender 2.8 isn't fully optimised yet. In blender 2.79 you can add a cube with a subdivision modifier with 11 levels of subdivision (50M tri) and you can easily move in interface, connect and disconnect node of the material of the cube, but in blender 2.8 there is more drawcalls, so it have less reactivity)
You can if use multiple GPU for cycles rendering to have one GPU for cycles, and another for the open gl user interface.
But i think when it's CPU drawcalls (like building of BVH) it freeze all the rest of the user interface, and it's sometimes frustrating to cancel an action.
* @yoann softyoda * my point is that you can easily see UI slowdown when nothing is happening! no BVHtree being built, no rendering. just geometry sitting in the background idle, not even in edit mode.
* @testure * Yes, I understood, I was just pointing out the importance of a separate process, or a second GPU to try to solve these problems.
But I made it clear that on the 2.8 there are more drawcall bugs than in 2.79 (you can test it with a cube with a modified subdivision surface at 11, there is way more drawcalls or process like that that happen where it shoudn't be, even hide collection make the rest of the .blend laggy, it shoudn't be in RAM)
Part of the difficulty here, I'm sure, comes from the fact that the entirety of Blender's interface is drawn in OpenGL. The same resources that are used to render your scene in the 3D Viewport are also used for drawing the interface. Typically, the interface doesn't have a substantial overhead to it. As an example, I've opened some fairly dense scenes in 2.79 (and older) and haven't experienced the UI slowdowns you're describing. So I wonder if it's a side effect of the massive OpenGL update Blender's had in the 2.80 series. If that's the case, this might be considered a regression bug. Could be worth it to report on developer.blender.org and see what they say.