Performance Issue: Background Calculation and Brush on Support are barely usable together

[J0nnyI]

Description of the bug

When using background calculation and brush on support, each time you lift the mouse-button, the masking gets applied and the Gcode gets generated.
This slows the Ui down to an unusable degree during support generation.
This is normally an non-issue since you take some time to change the settings, but that's not the case with brush on support

Project file & How to reproduce

Note: this has been translated from German to English, which means that some setting-descriptions might be off
1.- Enable Settings/ General (1st tab)/ Background Calculation (1st section, 3rd checkbox)
2.- Add an Model (mine had a lot of small overhangs)
3.- Disable Support
4.- Enable Support for the specified model
5.- add brush-on support to the model (use some smaller strokes for finer adjustments, this causes the UX issue)

Default 'Original Prusa i3 MK3S & MK3S+' Profile, Esun PLA, Derivation of 0.15mm Quality profile

The model is licenced and therefore must not be uploaded in any way

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.4.2

Operating system

Windows 10

Printer model

Prusa I3Mk3s

[kubispe1]

Hello, Thanks for your report. I tried it and it is exactly as you have mentioned. Can you suggest some solution you would like to have for this case ?

[neophyl]

How about suspending the background processing while in this sort of task until you exit that mode or adding a reslice now button to the form to manually trigger the slice.

[kubispe1]

Nice :D , I would prefer "suspending the background processing while in this sort of task until you exit ", cause there are quite a lot of buttons right now...

[neophyl]

Well normally the shortcut for reslice (cntrl+r) would cover it but lots of people seem to be allergic to those :)

[gudvinr]

Hello, Thanks for your report. I tried it and it is exactly as you have mentioned. Can you suggest some solution you would like to have for this case ?

Maybe just use less threads for background processing so system won't starve for resources?
I am not sure about internals of PS but if during slicing background threads frequently interact with UI thread that could lead to issue in question too. In that case slicing should be isolated more and do not block UI thread while it is working.

[J0nnyI]

The default solution I use for for problems like these is adding a debouncer.
Waiting for i.e. 10 seconds during which no settings change (timer reset on change) and only then triggering the Slicing process would probably an improvement for the entire application.
The user gets the best of both worlds, if the settings (timing and isEnabled) are made configurable

[foreachthing]

Well normally the shortcut for reslice (cntrl+r) would cover it but lots of people seem to be allergic to those :)

A shortcut to toggle background processing would be nice.

[gudvinr]

A shortcut to toggle background processing would be nice.

That sounds more like a bandaid rather than actual solution. When you force user to deal with issue rather than solving core of the problem (which is terrible UX due to choppy UI interactions) it doesn't improve overall experience.
Surely such shortcut can be useful in some use cases, most of which probably very niche but it won't solve underlying issue.
What @J0nnyI suggested makes more sense from practical standpoint.

[foreachthing]

That sounds more like a bandaid rather than actual solution.

Agreed.

Surely such shortcut can be useful in some use cases, most of which probably very niche but it won't solve underlying issue.

No, it would not solve this issue here, but it would help me with complex models and not having to go to properties all the time. I change this setting usually multiple times per day I 3D-print ...

[Area5142]

Maybe lowering the priority on the background slicing thread when in a tool and raising it again when leaving the tool to give more response to the UI.
Only works if the slicing process is running on a thread that can be prioritized.