[Feature Request] Add background processing toggle to main interface

[Sembazuru]

Version

Version 2.4.0-alpha1+win64

Operating system type + version

Edition Windows 10 Pro Version 21H1 Installed on ‎2021-‎03-‎30 OS build 19043.1165 Experience Windows Feature Experience Pack 120.2212.3530.0

3D printer brand / version + firmware version (if known)

Original Prusa i3 MK3S (Not that it matters for this feature request)

Behavior

I often toggle background processing on and off depending on what I'm doing. For initial layout, especially for very large models or very full build plates it is faster to have background processing turned off. But when tweaking settings it is nice to have background processing on to make getting updates to settings changes a little more streamlined.

It would be nice to be able to toggle this on and off without having to go all the way into preferences. A good location might be at the top-left next to the Simple/Advanced/Expert switches.

Is this a new feature request? Yes, this is a new "quality of life" feature request.

Project File (.3MF) where problem occurs

N/A

[MNeMoNiCuZ]

Agreed. My preferred location for the switch would be bottom right, near the "Export G-Code"-button. I think this is how it is in Cura Slicer.

[Sembazuru]

I was considering suggesting close to the Export G-Code button, but thought that area of the UI was already pretty crowded. But anywhere on the UI would be good.

[bubnikv]

Would a hot key be sufficient?

po 6. 9. 2021 v 8:28 odesílatel Chris Elliott @.***> napsal:

I was considering suggesting close to the Export G-Code button, but thought that area of the UI was already pretty crowded. But anywhere on the UI would be good.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/6893#issuecomment-913379244, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI2543IDD73CAFGHRJDUARNSPANCNFSM5DM7LZSA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[MNeMoNiCuZ]

I think a hotkey would be an improvement, but it would require a system message saying it was toggled. How about putting the checkbox to be only visible while it's slicing. This way it doesn't take up UI space when you're not slicing.

Similar to how the "Cancel"-button only appears when slicing.

[Sembazuru]

@bubnikv I agree with @MNeMoNiCuZ that while a hot key would be sufficient, I would like some sort of indication on the UI of the status of the switch.

I do understand the reluctance of moving the preferences settings outside of preferences. I just think that the background processing is one that would benefit from having easier access for workflow reasons.

[dartrax]

How about talking how the backgound processing can be improved so that such a toggle isn‘t neccessary?

I noticed that it got really good in not disturbing the workflow, compared to a year ago or so. But it still needs to improve when I move objects around. When the background processing finishes while I‘m moving an object, I will lose the object, it jumps back (#6898).

What are your pain points with background processing?

[MNeMoNiCuZ]

Just some brainstorming below, not well-thought-through:

The auto-slicing is mostly annoying when you have a heavy file (like 500k+ polygons), where the slicing time takes a lot of time, and slows down your machine.

1. I think that we could probably do without a toggle, if it stopped processing once you continue changing things, and then only after you stop touching stuff, it auto-slices.

2. Possibly it could also start by not slicing with full CPU power. This way your machine doesn't immediately slow down as it's trying to slice as hard as possible right away. Let it warm up for 5 seconds, then go full steam ahead. This is likely only relevant in heavy files, which you could probably detect. So that it auto-slices small stuff right away and doesn't cause delays.

3. It also starts background processing, even if you just changed something that isn't relevant to the slice (to my knowledge), such as changing the filament color (not changing filaments, just the color of the preview by clicking on the filament color. Maybe there's a reason for why it needs to reslice, but a simple change like this would ideally not re-slice the whole thing, just modify any color value baked into the .gcode (if any is there).

4. If an operation that causes a re-slice would know which part of the slicing it would affect, so that it would only update those parts of the final file. This way slicing would be faster. Not sure at all if it could be segmented like this, and it's not relevant to this topic exactly, but increased slicing speeds by chunking it up makes sense to me. If I tweak the first layer speeds, maybe the whole file wouldn't need to be re-sliced.

5. Why do we want to use auto-slice? The reason for me is that when I make small changes, it's nice not to have to leave the Print Settings to re-slice. When viewing the Print Settings, these options are full-screen, the sidebar with the slice-button is not there. I don't see why it couldn't be there. Even with a vertical screen it's not a problem to see the full sidebar and still have plenty of space for the options in Print Settings.

6. There could be a global hotkey to slice. If it would work in any part of the editor, I think this may be more powerful than auto-slice. But it would need to be something good, like how TAB goes between 3D Editor View / Preview, but CTRL + TAB toggles between plater and print settings, or SHIFT + TAB toggles the side panel. I could see "F5" be a good update to "trigger a slice"

[dartrax]

regarding 5, I use a separate window for slice settings on the second screen, so while it’s still nice to save a click that’s not my issue. The reason for me is speed. I‘m used to simplify3D with its superfast slicing. When Slicer begins to slice in background even before I‘ve decided that I‘m done with the settings (and thus, before I would init slicing), it finishes earlier and so it feels as fast as Simplify3D (well, mostly and not for big files).

I agree to your other points. Shouldn‘t it be possible with multithreading that the machine doesn‘t feel slower? I know @supermerill plans to improve things here: https://github.com/supermerill/SuperSlicer/issues/932#issuecomment-802098267

[supermerill]

Shouldn‘t it be possible with multithreading that the machine doesn‘t feel slower?

Prusa just introduced some multithreading for gcode creation in the last alpha. Almost everything should be multithreaded now.

[dartrax]

Yes, I got a significant increase in speed, it's really a great feature for me. I did not had to work with large files recently, is it still an issue for you, @Sembazuru?

[Sembazuru]

My apologies, I haven't had a chance to play while alpha 2 was in play. The issue that I had that I wanted to be able to easily toggle background processing on and off was general laggyness on complex models. I have a lithophane stl file that I generated with way too many triangles (over 3M) and unlike 2.3.3 the 2.4.0a3 while still a little laggy until I simplify, the lag doesn't make PrusaSlicer nearly unusable. Yay for multi-threading on my i7-10750H processor. I haven't tried with a multi-part layout with multiple modifiers meshes, support enforcers, variable layer heights, etc. yet though.

[HeatPhoenix]

Seconding this as a feature that would be deeply appreciated. The speed of your computer is irrelevant when you're slicing a 30 MB model every time I add a stroke of enforced supports, making the program impossible to work with.

Speaking of improving the performance so that this button isn't necessary fundamentally misunderstands the issue: Eventually, a user (maybe you) will have to slice something complex enough that performance just isn't going to be high enough that reslicing every 5 seconds won't lead to a bad experience.

[BloodyRain2k]

I also second this request. Most models I print are small, and there I prefer the slicer to update automatically, but on larger models, where every tiny change causes a re-calc of 5 sec up, often also causing the UI to stutter due to multi-threading doing exactly what it's meant to do: maximize CPU usage, then I do NOT want it. And having to go into the options each time is a little annoying.

Currently I'm trying it out to just slice manually with ctrl+r, which kinda works, but I would still like this feature.

Even better would be if the slicer could detect itself that the current setup takes a certain amount of time for re-slicing, and if that falls above a user defined threshold then it turns auto slicing off until the slicing becomes faster again. Be it from changing settings or removing models.