UI Constantly Operational - UX is the main goal

I would like to ask you dear Developers, what do you think about that kind of improvement for Blender when it is always operational - no matter what complex function is computing at the moment - UI/UX still works ?

I am not a good programmer and do not know Blender API at all and mechanisms of OS to App comunication.

These are my thoughts about this topic so maybe they could be a base to find a good solution for a problem when user is a slave of all Blender doings.
In my thoughts the USER is the key-character in Blender workflow, so Blender have to give him full manageability and access to the interface no matter what is going on at the moment.

Imagine the Blender App as an Onion where we have these layers of loops (counting from the most external to most internal one):
Main App Loop (MAL) [very long time for lap]->
Complex Function FIFO Loop (CFFL) [long time for lap]->
Panels Content Redraw Loop (PCRL) [medium time for lap] →
UI/UX Loop (UUL) [short time for lap]

MAL calls function that contains CFFL.

CFFL does all complex functions that need potentially huge amount of time to compute ( like modifiers ).
CFFL does all required functions in FIFO ( First In - First Out ) so it does all commissioned by user functions one after another. If object has a complex function / modifier to be computed on it then in UI it can show this object as “grayed” with some circle loading icon and add the job to the FIFO.
UI could have dedicated panel with Jobs List that are queued and processed.
Most important thing is that the CFFL calls the function with PCRL own loop.

PCRL does all Blender Panels actions like redraw the content ( but not waiting for final execution if for example SubDivision modifier is still computing and have not given output mesh for display )
PCRL is called by an interrupt timer for at least every 200ms for example, no matter what loop is currently processed by CPU.
PCRL works like that (this is just a quasi-language just for actions description):
#1: CLEARTIMER {PCRL} // to avoid rerun when it is processed at the moment
#2: CALL {UUL}
#3: LOOP *// processing all panel doings
#4: TAKE {Action} FROM {PanelsFIFO}
#5: EXECUTE {Action}
#6: UNTIL {PanelsFIFO}
#7: SETTIMERCALL {PCRL} TO 200ms *// set interrupt timer for PCRL

UUL takes care of user actions and tries to allocate them to proper FIFO
It is called from timer interrupt so even if some content of panels is redrawing the Interface still works fine.
All depends on user how “heavy” this call will be. If user do many things with UI then this will be the most processed element. But if user wants to wait for finishing the functions he commissioned then will not be using the UI and will wait. So it means that the UUL call will be very short.
So this is how User decides what is most important thing to process by application.
UUL works like that:
#1: GET {KeybMouse} TO {Readings} *// taking information what user did with interface
#3: TAKE {Action} FROM {Readings} *// analyze if user doings make any actions to process
#4: LOOP
#5 ANALYZE {Action} FOR {certainFIFO} *// sorting Actions and adding to certain FIFO
#5: CASE {certainFIFO}
“PanelsFIFO_type”: PUT {Action} to {PanelsFIFO} *// FIFO for Panels doings
“FunctionFIFO_type”: PUT {Action} to {FunctionFIFO} *// FIFO for Complex Functions
#6: UNTIL {Action}
#7: SETTIMERCALL {UUL} TO 50ms *// set interrupt timer for UUL call

Maybe this what I wrote is wrong. I do not know.
But I think that the direction for giving user more important place in whole application processing should be the goal. Users are humans so they can be very nervous and impatient when application is not responding. :slight_smile:

we have 2 posts about UX at the same time:

Blender Foundation has money from Epic Games and will have some from nVidia and probably more corpos. So I think that @Ton should very seriously consider the UX development to make Blender more user friendly and operational no matter what application is computing in background - UI always should be available for user.
My proposal is just a simple scratch of concept. But the main idea could be implemented somehow.

So question about having a programmer is a question for @Ton , not for me.
He is set directions of Blender development and now has much more money do manage for this, so it makes me very happy and very optimistic for the future of Blender.