On a box with an 8-thread Intel i7-860 and 16GB of RAM, it takes several minutes to load a 5M STEP file.
During this time, other windows cannot be moved, although window focus can be altered, and menu items opened, then to also freeze.
It was not obvious for a while that the PC had not seized up!
This should, in my view, never be so. The slowest things are us, and our mouse, and our typing. The highest priority should be given to the slowest stuff at an acceptable sample frequency. The interrupt is tiny, from when it can return to the really big task. We should never feel out of control, locked out, and ready to reach for the power switch.
If the attempted file is so large the program will choke on it, then a warning, a progress indication, anything to let us know things are not hung up. While my thanks goes to the heros who make this great tool, I do not have the skills to try for a fix, so treat this as a feature request.
It would be nice if sufficient feedback that "it lives" is provided, even if the load is challenging.
FreeCad 0.19 inhibits desktop during STEP (.stp) file load.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
Be nice to others! Read the FreeCAD code of conduct!
Re: FreeCad 0.19 inhibits desktop during STEP (.stp) file load.
Perhaps such loading could be handled similar to CheckGeometry.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: FreeCad 0.19 inhibits desktop during STEP (.stp) file load.
Always add the important information to your posts if you need help. Also see Tutorials and Video tutorials.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
Re: FreeCad 0.19 inhibits desktop during STEP (.stp) file load.
I had thought about asking for the full FreeCAD infos, but I think they are not helpful here. This asks for a more general, system independent approach.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: FreeCad 0.19 inhibits desktop during STEP (.stp) file load.
This is a pure Operating System responsibility. A single program does not know interrupts or any kind of sheduling, but expects a uninterupted sequence of commands. Switching computing time between multiple programs and prioritization is one of the most fundamental parts of a OS. Also when program uses all CPU power and all memory the OS has to handle it, not the programm itsef. I think you need to look into the system settings, maybe by accident to set FreeCAD to higher sheduling priority than other tasks?This should, in my view, never be so. The slowest things are us, and our mouse, and our typing. The highest priority should be given to the slowest stuff at an acceptable sample frequency. The interrupt is tiny, from when it can return to the really big task. We should never feel out of control, locked out, and ready to reach for the power switch.
This is definitely something to improve on FreeCAD side. There is already a progress indicator for the loading part, I think was not works yet with the progress bar is the tessellation of the parts after loading, and this could take some serious time (also dependent on your "deviation" setting)If the attempted file is so large the program will choke on it, then a warning, a progress indication, anything to let us know things are not hung up. While my thanks goes to the heros who make this great tool, I do not have the skills to try for a fix, so treat this as a feature request.
Re: FreeCad 0.19 inhibits desktop during STEP (.stp) file load.
No, this is clearly a FreeCAD bug, and has been reported also about large imports. And it's not an importer problem, because it happens also when opening a large native FreeCAD file (77Mb) :
The mouse stays responsive during the openening (~3 minutes) but not the keyboard, the keyboard input is probably grabbed by something, across the entire desktop, while the mouse works without a hiccup:
OS: Ubuntu 18.04.3 LTS (KDE/plasma)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.19323 (Git) AppImage
Build type: Release
Branch: master
Hash: 1b198453b8eb6aa2eaca4e4be4b49fee74e9de6e
Python version: 3.8.1
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: English/United Kingdom (en_GB)
Re: FreeCad 0.19 inhibits desktop during STEP (.stp) file load.
Ah, I understood the post differently, thougth it's about using 100%CPU and with that locking up the other UIs. If its grapping some systmem inputs you are rigth, that would be a bug.
Re: FreeCad 0.19 inhibits desktop during STEP (.stp) file load.
This doesn't happen with realthunder's FreeCAD-asm3 branch (from 2019/06/10). The UI remains perfectly responsive. And STEP import is also better.
OS: Ubuntu 18.04.3 LTS (KDE/plasma)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.16830 +1496 (Git) AppImage
Build type: Release
Branch: LinkStage3
Hash: 1b29767b545440b7ab93f1a5f2b742d622f1b547
Python version: 3.7.3
Qt version: 5.9.7
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedKingdom (en_GB)
Re: FreeCad 0.19 inhibits desktop during STEP (.stp) file load.
I had a similar problem in two different contexts (under Xubuntu 18.04):Zolko wrote: ↑Wed Jan 22, 2020 2:01 pmNo, this is clearly a FreeCAD bug, and has been reported also about large imports. And it's not an importer problem, because it happens also when opening a large native FreeCAD file (77Mb) :
1. When starting FreeCAD in command line mode or loading in a Python session and then loading its GUI module I could not type any more into the terminal window (as a visual feedback the blinking cursor was not filled white but only had a white frame and inside it was black).
When I minimized the FreeCAD window in the task bar I could continue to type something into the terminal.
2. I was debugging through the code in QtCreator to find a bug. The widget quickly popped up and was still visible. Afterwards it was not possible any more to click on QtCreator so that it gets the focus in order to continue debugging. Also trying to minimize the FreeCAD or pressing the shortcuts to continue debugging did not work. The only option was to switch to a login shell and killing the debugger.
And quite often I have a similar situation that pressing the keys to step through the code stops working because of a focus issue and I then have to click the command buttons in QtCreator with the mouse.
IMO, the issues are related and the root problems seems to be that on some DE clicking on a window does not make it to get the focus (due to some weird DE settings). In https://forum.freecadweb.org/viewtopic. ... 84#p359995 I have linked a possible solution (which I have not tried yet).
Besides this I think the point is that when FreeCAD is busy or is being debugged its event loop is not responsive/running and that's I guess people run into problems. If RT branch does not show this behaviour and probably because he may have added some explicit calls to process pending events.
But IMO then in the first place this is not a FreeCAD bug but as said due to weird default settings of the DE.