-
-
Notifications
You must be signed in to change notification settings - Fork 307
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] GUI startup delay #1403
Comments
Please see discussion in #749. What you are reporting is surprising to me, we have already taken some steps to mitigate this problem. At the same time I assume we could improve it. However, loading is already done in the background and should be run in parallel (on the level of locations). So when I start gui, I can immediately start using it. I tested large number of layers and I get nowhere close to 30 s. I found what takes time is showing the content of a mapset (current mapset is unfolded by default), can you see a difference depending in which mapset you start? Also how are your data distributed, e.g. do you have a lot of locations/mapsets or rather a lot of rasters/vectors in a few locations/mapsets? |
As I mentioned before #749 (comment), working with wxPython 4.1.0 increases significantly the startup speed, even though it could always be improved. As a general note I must say the new GUI is a major step forward against user friendliness and productivity. Please do note the new possibility to use several |
@nilason Please don't get me wrong. I'm not saying that the new startup is bad. I like it and it can be a game changer for any GRASS users. I just want to help improve it. Reorganizing my database is only a workaround and it would impact my workflow. Having to reorganize my data every time something new is added and slows me down is just not a solution. |
I have 18 locations and 49 mapsets in total. My CPU is rather old (Xeon(R) CPU E5620 @ 2.40GHz) and I have an HDD. It could be the issue. I just created a new database and tried an empty mapset. The GUI displays all databases anyway and it took almost the same 32 seconds. I can see it does a kind of a background process because clicking different tabs or buttons responds slowly until the hourglass icon is cleared. For example, I can immediately switch the tab to Display and clicking other tabs doesn't seem to work. Click the raster icon and wait about 5-10 seconds and the dialog eventually opens. By that time, I already clicked other tools multiple times and all of a sudden, all those dialogs open at the same time. I tried my relative new laptop (i5-7300U @ 2.60GHz) with an SSD. There are 4384 vectors and 2740 rasters across 26 mapsets in 7 locations. It took 7 seconds to clear the hourglass. That's about 59% of the above computer in the number of maps and 23% of the delay. Maybe, it's my old CPU? |
@nilason I don't think this method actually works because the GUI lists all my previously opened databases no matter where they are. Looks like the GUI caches this list. @petrasovaa Would it be possible to load just the current mapset, location, or database optionally for a slow computer if the issue is my machine? Until the user opens something else? I mean as an optional setting. |
I cannot reproduce this. I have used different databases, but I don't get all of them listed.
AFAIU, this is the default behavior. I only get the maps in the current mapset listed. To see others, I must click on them, and according to the number of maps there, it takes shorter or longer to load (micro seconds to seconds). Just to be sure, do you use the newest grass-dev? |
Seems like there is some confusion around databases here. You can add a database and that database is then saved in settings so GUI remembers it for next time it is opened. If you remove it from data catalog, it's removed from settings and disappears.
No, at this point everything is loaded (in a virtual tree), but only current mapset is displayed. I agree we should limit the loading for slow computers/large databases. The loading could be limited to current location only for example if it takes too much time and the rest could be reloaded on demand. The changes are feasible, but not super trivial. |
By listing databases, I meant that visually collapsed databases are listed under the tree. I still have to click one to expand it.
From my experience, the GUI seems to load everything from listed databases, not just from the current mapset or current location or not even current database. |
Oh! I didn't know that. Then, how can I add them back? By starting in a removed database from the terminal? Or does the GUI have a button for adding a database?
Ideally, it would be best to load only the current mapset on start, and load other mapsets on demand. Mapset by mapset, not location or database based. Or make it configurable? Sounds like I'm asking for too much ;). |
In the data catalog toolbar there is Add existing or create new database and when you right click, there is Remove GRASS database from data catalog.
Loading only current mapset is fine, configuring it might be too much at this point... |
That'll be great! |
Not quite complete, but please try #1434. |
@HuidaeCho can you tell us if this is still a problem ? |
This was addressed by #1434 which is now merged. Please open a new issue if needed. |
Describe the bug
I have 5367 vectors and 6759 rasters in many mapsets/locations in my GRASS database. When I start GRASS GUI, there is about a 25-second delay (hourglass cursor) and I cannot do anything during this wait in GUI. It doesn't matter in which mapset I start. Even from a brand new mapset without any data.
To Reproduce
g.gui
Expected behavior
Load the Data catalog in the background.
OR an option to disable and remove the Data catalog.
Screenshots
I cannot show my time.
System description (please complete the following information):
Additional context
I would have a faster GUI than a user-friendly but slow one. Ideally, any long-running tasks should be done in the background to enhance user experience. Please do not assume that there are only a handful of maps in one database.
The text was updated successfully, but these errors were encountered: