Settings guide plugin often freezes Cura
PhilBaz opened this issue · 25 comments
Initially raised the issue at Master fork here:
I'm unable to reproduce this issue. Could you provide a log file of Cura, to see what's going wrong on your end?
@Ghostkeeper Here you go.... I just opened Cura, sliced a box, and then accessed the settings guide through a right-click on a parameter. Settings guide works fine, but after I close it Cura becomes slow and unresponsive, then the 'program not responding window' pops up where I quit. This happens every time I use settings guide through right click.
Don't forget I'm using the smart avionics master fork..
Thanks!!!...ps zip'd it for compatibility with git upload.
@Ghostkeeper seems to do the same in 5.0 as well.
Hmm, well the log file doesn't show the crash itself. That's probably because it seems that the crash is in Qt or some C++ library that Cura uses, not in the Python code of Cura or the Settings Guide.
The log does show a hint though:
file:///C:/Program Files/Ultimaker Cura 5.0.0/PyQt6/Qt6/qml/UM/TooltipArea.qml:0: ReferenceError: Tooltip is not defined
It seems that it can't find the tooltip QML element. It shouldn't cause a crash like that though, so we might be hitting a bug in Qt there.
It's frustrating though that it doesn't reproduce on my side.
I want to update that my Cura instance with your plugin was slowing down Cura significantly to the point I couldn't do any action on a rather powerful machine.
After uninstalling, I no longer experienced the lag, freeze and Crash on Cura 5.0
@Ghostkeeper Yeah, I'm still getting the freezing/lagging when I open the full SG from the menu. I have it on as a tool tip but sometimes wish to look through.
I'm on the latest version of everything. Anything I can do to help track down the issue?
I want to update that my Cura instance with your plugin was slowing down Cura significantly to the point I couldn't do any action on a rather powerful machine.
After uninstalling, I no longer experienced the lag, freeze and Crash on Cura 5.0
I consider this a different issue than crashing. It'd be best to open a different ticket about it.
The settings guide is supposed to load the articles in the background, which shouldn't impact Cura's performance except for other tasks that are also done in the background, which includes loading an STL file (basically anything that shows a progress bar in the middle-bottom of the screen).
I'm on the latest version of everything. Anything I can do to help track down the issue?
I don't know. I can't reproduce the issue, and don't see anything obviously wrong with what the Settings Guide does to tooltips. I hope that more people may report this issue so that we can see what the commonalities are between them.
Hi,
I get this problem from time to time, and it's always linked to Microsoft PowerToys. I just quit PowerToys and the problem vanish.
With Cura 4.x I did exclude these .exe from Fancy Zone: Cura.exe, CuraCLI.exe, CuraEngine.exe
Today I got the problem again. I updated PowerToys, no change. Then I added those two .exe from Cura 5.1: Ultimaker-Cura.exe and conhost.exe, but it still slows down Cura. Until the next PowerToys update I just have to remember to quit it before using the setting guide in Cura.
The problem right now is mainly when I try to collapse a category. I click on the Material to expand or collapse: “Not responding”. Quit PowerToys: Magically unfreeze.
Hope this help
Good evening, I wanted to report the same issue that @PhilBaz is reporting.
It also hangs to an unusable state after opening and closing the Settings Guide main window.
Additionally, @PhilBaz apologies for being nosy, but your logfile you posted appears to be an instance of cura that does not actually have settings guide plugin installed? I don't see it loading, searching for - INFO - [MainThread] UM.PluginRegistry.loadPlugin [493]: Loaded plugin SettingsGuide2 2.9.0
I recently cleared all config files from %AppData%\Roaming\Cura
and %AppData%\Local\cura
as well as clean installs and still got the issue.
I just saw and installed the ExtensiveSupportLogging plugin and am going to clear all profiles again and do a bit more troubleshooting, so hopefully I can get you better logfiles really soon.
I think i figured it out!!
at least for my environment.
My conclusion after resetting cura several times as mentioned above and messing around.
The more print settings that are visible (enabled) AND expanded in the print settings pane causes the stall when settings guide is opened and closed.
If I collapse every single print setting category, everything is fine. If I expand all of them, settings guide interaction (the window not the tooltips) causes cura to get stall and become unusable.
If a have one or two categories open (small ones). opening and closing settings guide doesn't cause a hard stall, but it gets very unstable and laggy. if I collapse all print setting categories, everything is fine a again.
I am unsure if logs say much even with the ExtensiveSupportLogging enabled that can narrow down what is causing it.
At least nothing pops out to me, but I am also quite the novice, even with cura and 3d printing. Which is why i rely on the print setting guide plugin so much, i love it. I honestly kind of wish it was its own application or even website. If I could export it to use as a standalone site, I would, but it just isnt the same.
I performed two "trials" where I started with wiped profiles by deleting %AppData%\Roaming\Cura and %AppData%\Local\cura.
I put exactly what I did for every session that cura opened and closed in a text file called "methodology".
Troubleshooting.zip
Thanks for the investigation and the clear methodology. It appears though that @SkepticNerdGuy has a different issue from the originally reported issue because it appears that for them, Cura freezes instead of crashing.
I've repeated your steps, but for me Cura doesn't freeze, not even for a fraction of a second, upon closing the guide. So it's definitely different on different computers. The logs don't say a lot. ExtensiveSupportLogging doesn't add more things to the log (aside from when it starts and stops logging) but it does create a separate file if you start/stop logging. A PStat file should get written into the exported Zip file. This PStat file stores how long all of the Python code in Cura takes to execute, including the Python code that's part of the Settings Guide. I don't know if it would really show anything because the freeze could just be in Qt rather than in my code.
If I could export it to use as a standalone site, I would, but it just isnt the same.
The guide is made to also be readable on Github with its Markdown viewer: https://github.com/Ghostkeeper/SettingsGuide/tree/master/resources/articles It has two differences then though:
- The article files are not listed by their translated setting name, but by the internal name in Cura.
- You'll only see the article for the most recent Cura version. The Settings Guide normally hides or changes some text depending on the current Cura version you're using.
(feature request: when a new setting is requested via right click option, the settings guide window resizes even if I have it maximized on a second screen. wish it stayed maximized)
I'd consider this a bug, yeah. Separate from the issue reported here of course.
Just want to clarify that my Cura does freeze. perhaps I used the term crash improperly. The program doesn't exit, it simply locks up to the point it is not usable.
@PhilBaz Out of curiosity, can you try re-creating your issue that causes the freeze, with all settings panel categories collapsed, and see if it evades the freeze like it does for me? Then again with all settings panel categories expanded and checking if it does freeze?
@Ghostkeeper ExtensiveSupportLogging appears to create a YAPPI profile, rather than a PSTAT file. I started looking through how to read/parse the output. So far, with the documentation and also teaching myself basic python (haven't programed in a decade) I got yappi to load the file and i think i got it to convert it to a PSTAT file as well. I wanted to see what exactly was on the file before sending it, since it saves it in a binary format.
Yes! this appears to have something to do with it. The number of open panels appears to be relevant and having all but one closed produced almost no freezing. Maybe just a touch of lagging after.
After opening all my usual panels and going through again Cura is now frozen...
@SkepticNerdGuy Nicely done!
Sounds like a good deal.
@Ghostkeeper i finally wrote a python script that imports the .yappi file that the yappi profiler creates and outputs two files as txt. One of the files the output of 'stats.print_all()' and the other is 'stats.print_debug()'.
I ran out of time last night to run it on a profile that I know has the lag/freezing going on and I have a few too many to really figure it out which is which. I'll clear my exported logs and then run cura with the profiler twice. Run 1 will have conditions that will NOT cause the program to freeze (wont expand settings panel categories), run 2 will have conditions that WILL cause the program to freeze. I upload the txt files when i get those done. Hopefully there will be some insight to the cause.
Also have it set up to output as pstat file, and want to play with snakeviz to take a look.
Not gonna lie, im having a bit of fun teaching myself how to do this.
@Ghostkeeper do you happen to have a private way I can send you my PSTAT, YAPPI and outputs to you? I can't modify the folder structures in the binary output (i just dont know how) and did not want to post them publicly.
A Yappi profile works just as well for me. Sorry, I forgot what the exact output was.
Nice to hear you're having fun :) Lots can be learned from profiling.
You can send a profile via e-mail to me, to rubend at tutanota dot com (the same address as listed here).
File sent!
let me know if you need any other conditions created and logged.
This is the relevant data from SkepticNerdGuy's profiling, analyzing as I write...
This is the profiling from when it did freeze:
And this is the profiling data in a run where it did not freeze (with the setting categories closed):
The relevant ones for the Settings Guide are the manipulate
functions and the InlineLexer
functions, which are part of the Mistune library that the Settings Guide uses to parse the Markdown files for display.
This confirms the way that I think it should work: The Markdown parsing takes quite a while for SkepticNerdGuy, about 8 seconds in total (some functions from Mistune are not visible in these screenshots). However it's done on a separate thread in the background, so it shouldn't affect the application. Apparently when the setting categories are closed it indeed doesn't affect the application, but when they are open it does.
I don't know how that could be different. As far as I know Cura loads the setting properties all the same whether the categories are opened or closed. But perhaps the difference could be that Qt is waiting on the display data when they are opened, somehow. And even though the setting description is not actually shown yet and never shown all at once, the setting descriptions may all have been sent to QML causing Qt to wait for all of it to load?
None of this explains why this started becoming a problem since May. This didn't recently change in the Settings Guide. The last major change that could've affected this is the change that made the guide be shown in the setting tooltips by default, but that was like 3 years ago. Maybe Cura 4.13 changed it, when the settings list was changed to use QtQuickControls2?
Talking workarounds, I think these are the options here:
- As a workaround, you could have only your favourite settings visible and use the search bar for the rest. This is the intended way of working with Cura, and makes a lot of difference for performance, instead of having all settings visible. It also really improves the workflow a lot for making it easy to find settings you use often.
- As an alternative workaround, you could indeed have the setting categories closed and fold them when no longer in use.
- Or you could disable "Show articles in setting tooltips" in the Settings Guide's preferences.
As for fixes, I think there will always be the problem of having to open up lots of files and parse them for the setting descriptions. It's just a lot of data for Python to process, which is always going to be necessary if Cura requests all of the setting descriptions all at once. A few things I can think of:
- We could try updating Mistune to use Mistune2. This requires rewriting the Markdown extensions that the Settings Guide adds (to have proper themed link colours, to render images, and italic text compatible with Qt's Rich Text). It's no guarantee that the new version would be any faster though. Mistune's change log is rather minimal about what changed. It could also be slower (but have more features).
- We could cache the rich text translations in a cache file. I'm not allowed to use Pickle for this (due to security issues; the Settings Guide is subject to third-party security reviews) but it could replace the Markdown parsing with e.g. JSON parsing which might be faster. This could also have problems though, especially with escape characters which may make it slow again.
The first solution is one that should be done anyway. The old Mistune is stable and has no known security issues at the moment, but the newer versions are still supported for when a security issue is discovered.
I'm not sure if the second solution is worth it, really.
For now you'd have to do with one of those workarounds. But I'll look into upgrading Mistune.
Hey there, sorry for the delay. This is pretty awesome info. I am not super familiar enough with the functionality of the differnt libraries, but I think i understand some of what your saying with regards to trying to narrow it down.
This didn't recently change in the Settings Guide. The last major change that could've affected this is the change that made the guide be shown in the setting tooltips by default, but that was like 3 years ago. Maybe Cura 4.13 changed it, when the settings list was changed to use QtQuickControls2?
I honestly don't remember when I first started noticing the issues, It may have been in before the 5x release of cura,So it may have actually been brought on by the change in 4.13 you list above. I was probably either lazy to report or didn't make the connection as to why my cura was freezing and never though to really ask for help or anything. I also think it's because I've honestly have never been an interactive consumer of open source or someone who provides feedback with stuff like this. This I the most I've ever interacted in this kind of community. Which now I think I should do more often. Its been educational.
I'll try downloading a previous version of cura, wiping the configs and installing the plugin and see if it still happens. And if there are even older releases of cura+plugin (pre 4.13) i can do the same and see what happens, at least maybe narrow it down to a specific module/library like you suspect.
I'll also try to find some other hardware to recreate the problems too. I wonder if there's something (hardware/driver) that maybe just doesn't like something that's happening? Maybe my 5th gen intel chip hates python or something of the sort. I wonder what my and @PhilBaz 's PC have in common. Just some fun questions to ask that may also narrow down why this isn't that much of a problem for others, but both of us have the same exact issue.
As for the work-around, the plugin is amazing and not going away, and have basically already "trained' myself to collapse settings groups that im not adjusting. I like having most settings available to play with things, so this has already worked for me since I figured out what makes the lag worse.
same here..
I have the same issue of Cura freezing when using the Settings Guide.
As noticed by @jcdeshaies it seems to be linked to Microsoft PowerToys for me as well: As soon as I quit PowerToys or even simply deactivate its FancyZones feature, Cura unfreezes. When I reactivate FancyZones Cura freezes again. Note that it is not sufficient to put the Cura executable in the exception list of FancyZones.
So, currently my workaround is to deactivate FancyZones either before starting Cura or even as late as when it freezes. It consistently and immediately unfreezes when switching off FancyZone without even needing to restart Cura or PowerToys.
Edit: I have also reported this issue to the PowerToys repo: microsoft/PowerToys#24758
Also see this issue over at the Sidebar GUI plugin repository:
fieldOfView/Cura-SidebarGUIPlugin#24
That plugin has a very similar issue in combination with FancyZones. Perhaps we can find out what is going on together.
It would be great if you could test this "nightly" build of Cura. It seems to fix the problem with SidebarGUI, and I have a feeling it is actually the same underlying issue.