You don't need to wait until the whole toolpath is generated again, just ignore the toolpath generation and make any changes as if it was not there. The toolpath generator is a separate background process that is running on the lowest priority which should not hinder anything else you do in Cura. For that reason you have to make a very strong case before the lead developer of Cura would even consider implementing you feature request.
Dirkels, one that frequently bugs me is that if I have a model that takes a long time to slice, and then I decide to switch the settings for Support Type or Platform Adhesion, I am forced to wait until the slicing is done before Cura will allow me to change settings. If I try and change these settings before it's done slicing, the dropdown combo box will not stay visible long enough for me to do anything. That gets pretty old. I often have to resort to something like scaling the object down to be very tiny (so it slices quickly), changing the settings, and then scaling back up.
-Dave
The toolpath generator is a separate background process that is running on the lowest priority which should not hinder anything else you do in Cura.
That's true for some of the process, but not all of it. There's definitely something that happens when settings get changed that either uses or blocks the main/UI thread, resulting in an unresponsive application. Whether that's toolpath generation or something else, it would be useful to have an option to defer the costly operation until after all changes have been made.
The issue is more noticeable on slower machines (my laptop struggles a lot more than my desktop), and is particularly pronounced on the scaling inputs. So perhaps it's related to the rendering of the part in the preview view, although scaling the graphical model should be quite efficient assuming that it's done on the GPU. But load a moderately complex model and try changing one of the scaling options when the toolpath is just starting generation, and see how long it takes before your keystroke is even recognized. This takes a few seconds on my desktop (hex-core i7 @ 4GHz, 24GB RAM), and up to a couple minutes on the laptop (quad-core Q6600 @ stock settings, 4GB RAM). And it's sufficiently reproducible that the lead developer should easily be able to experience it for himself.
Though I see Cura is actually open-source. If I get some free time I'll poke around and see if I can come up with a patch/pull request.
Though I see Cura is actually open-source. If I get some free time I'll poke around and see if I can come up with a patch/pull request.
Good luck. I have a pretty good idea what is blocking the GUI, and fixing it won't be easy.
(Disabling re-calculation does not remove the effect you are having, hench the reaction to these requests)
+1 vote for a start slicing button...
for now I load the (multiple) parts, move them quickly from the buildplatform and when they are grey start turning and twitching.
+1 vote for a start slicing button...
for now I load the (multiple) parts, move them quickly from the buildplatform and when they are grey start turning and twitching.
Neat trick! :-P
If I understand Daid right the problems many seem to have (I'm either to slow or only work with simple objects) in the GUI don't go away if you stop recalculated tool path every time you change a setting.
After some quick initial investigations, I've found:
I agree that 'fixing' the method itself would not be easy. Or it might be, for someone who does a lot of graphics programming, but I'm not that guy. In any case, deferring calls to processMatrix() seems like it may help. Not a proper fix, but the UX can't tell the difference.
Developer question: Is the PrintableObject class used as a data-source for non-trivial things, or does it exist solely for the purposes of display?
deferring the processMatrix can cause hell in other areas, which depend on up-to-date model information to be available. But, yes, that's one of the main causes of slowdown.
As for the delaying of slicing performance, I do not notice any performance difference. But it might be interesting to test to see if it's the starting of the slicing, or the receiving of data that is causing the slowdown.
Wait, let me explain a few more things that could be messing things up here.
Another fine example of my shitty code. If you have multiple objects on the printer bed, and you print those "all at once", the GUI code (does this on a thread, but the PIL could be messing with you here) will calculate the final 3D model before sending this to the engine. With multiple complex models, this could potentially take quite a load on your CPU. Especially as it's also doing all the transformations then and essentially storing the model twice in memory. Recalculating positions so the final position of the object matches with what you want.
The plugins are run in the same Python instance as the GUI, so plugins will block the GUI (Due to the PIL once again) plugins can be a real slowdown if you have a lot of them enabled.
The Engine communicates a lot of polygon data back, the GUI is storing this. This is used to speed up rendering of the toolpaths, but storing this data could potentially be causing slowdowns.
When in toolpath view, GCode is parsed, result is stored, and then read again to be transformed into the shown toolpaths. This isn't as efficient as it can be. Totally rewrote this code for the PinkUnicorn.
So...
Hi,
I have read above posts, a little technical, but get the idea ( I guess 
).
I might not be the average Cura user, but I took some pictures from the workflow that suits me best.
I have an idea about the files I load, so choose the profile already.
Hit he load button
As soon as the models appear, move them away from the buildplatform in 1 sec before cura starts calculating.
Most parts I have to rotate and move. Prints a lot faster keeping the Bowden as straight as possible.
When the stones are in position, pull them fast in the right position on the buildplate.
No hesitations otherwise you have to wait until cura is done with the one yellow part.
On this computer there seems to be a delay off aprox. 1 sec before cura starts calculating.
When parts are yellow, hit layer view, go do something else for 2 minutes. check layers and save the gcode.
Hit normal view ( don't forget it!!) and load a new platform ( 400 stones to go ) Almost done 
And In my free time, still having fun printing at home .
But I do like a START slicing button!!!! :-|
Wait, let me explain a few more things that could be messing things up here.
. Totally rewrote this code for the PinkUnicorn.
So...
P.S.
Psst Daid where do I sign in to volunteer for a beta version off the PinkUnicorn????
and load a new platform ( 400 stones to go )
That sounds more like a job for.... scripting.
3dcase: Unrelated, but wth are you printing?
3dcase: Unrelated, but wth are you printing?
http://umforum.ultimaker.com/index.php?/topic/3883-project-egg/&do=findComment&comment=31972
Cool!
First, here's a patch for anyone who wants to try out the 'manual slice' version (go to 'File -> Preferences' and uncheck the 'Automatic slicing' option, and then slicing will only start when you hit 'Ctrl+T'): http://pastebin.com/GX1A4igz
deferring the processMatrix can cause hell in other areas, which depend on up-to-date model information to be available. But, yes, that's one of the main causes of slowdown.
If deferring the call causes issues, what about short-circuiting the costly part when possible? I'm assuming the costly part is where it iterates through each mesh to find the largest bounding circle that exists (if that's what it's doing?).
Based upon what little I understand from my cursory examination, it seems like the method is being used to compute bounding geometries, sizes, and offsets. In theory that means instead of performing the exhaustive search through each mesh every time a change is made, the new values could be worked out mathematically based upon 1) the previous values and 2) the nature of the change. For simple changes, at least.
For instance, scaling and translation seem like they should have very predictable effects upon the previously computed result. It's fundamentally the same, but multiplied by some factor (scaling) or shifted by some offset (translation). I'd say the same about rotation as well except it seems that somewhere along the way there's some accounting made for gravity/the build platform, such that a rotation can also trigger a translation along the vertical axis.
Perhaps you could even precompute the result once, and then supply data to the external world by applying whatever the current transformation matrix happens to be to the precomputed result(s), in an on-demand kind of way? If so it seems like that would be very fast, once the initial computation was completed.
Though as noted, graphics (and in particular, 3d-graphics) is not my area of expertise, so perhaps I'm completely wrong.
When in toolpath view, GCode is parsed, result is stored, and then read again to be transformed into the shown toolpaths. This isn't as efficient as it can be. Totally rewrote this code for the PinkUnicorn.
So...problem already fixed for the next release?
Edit: And one possible explanation for why the toolpath computation may cause issues for some people even though it's done on a background thread is paging. If the thread is allocating memory so that it can run its computations and the OS is forced to start paging things to disk, that can easily cause performance degradation in other threads (and processes, even). And then if the main thread keeps trying to bring the paged information back in...the two threads throttle each other and things grind to a near-halt.
Paging might also explain why my desktop seems significantly less impacted than my laptop; it has 6x the amount of RAM installed and is very unlikely to ever need to page anything out.
If paging is happening, then you're pretty much screwed anyhow. But I don't think Cura uses shitloads of memory, and any recent laptop should come with at-least 2GB of memory these days.
As for re-using, there are some many cases that can happen, and there is quite some geometrical magic going on at that point. Lots of it is done with numpy, which makes it even trickery (but loads faster)
Here's a patch that also moves the graphics/'processMatrix()' updates onto the manually triggered computation: http://pastebin.com/L6kKaRe4
Caveat Emptor
I haven't had time to test this thoroughly, but it seems to work as expected (I can rotate, scale, and configure my print parameters with zero delay, hit 'Ctrl+T', and then get a successful slice) and with only minor side-effects (if I scale an object outside of the build volume, it won't always turn gray until I hit 'Ctrl+T', etc.).
You might run into problems with one-at-a-time printing. As well as strange things when you try to place multiple objects on the bed (allowing intersections after rotating objects)
ArunC posted a topic in UltiMaker Cura,
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
Dustin posted a topic in Firmware,
Recommended Posts
Blizz 53
I've asked for http://umforum.ultimaker.com/index.php?/topic/6428-manual-refresh-of-render-time/ a while back.
The best solution that came out is to do all your settings with an empty buildplate, which I now do (if I remember)
Link to post
Share on other sites