minigalaxy has huge problems handling more than 100-200 games

[shakeyourbunny]

Hi,

can you do some serious optimizations on loading in the games? My GOG library is about 2500 games and I do have a beefy computer.

If I try to start minigalaxy it nearly dies due that it tries to load all games from my library page and also it tries to reload them if I do anything, eg:

• filtering games
• flipping switches in the option menu
• losing and getting focus of the main window.

Seriously, can you disable this continous auto-refreshing or at least have a switch for re-reading the games from the GOG online library (default: autorefresh = off)?

Also, do a progress bar (along side cancel refresh button) when doing a refresh.

Thank you

[sharkwouter]

Thanks for the report. We are aware of a refresh/loading games taking a long time, but it turns out to be quite hard to solve. It has improved from version 1.0.0 to version 1.1.0, but we're still not where we want it to be. Gtk unfortunately does not actually support multi-threading. I will revisit this, but it will still be slow in the next release. I'd like to have it resolved in version 2.0.0.

That losing focus causes a refresh is not inteded, though. Filtering should also not cause a refresh, but it might be slow for other reasons.

[LeXofLeviafan]

Gtk unfortunately does not actually support multi-threading.

Isn't it a GUI library? If the problem is with calculations, it doesn't require GTK involvement until you start rendering the data (and thus can be pushed to another thread by completely separate means); and if the issue lies with rendering, it's a well-known problem with a number of ways to resolve it (e.g. you could append data/UI elements to the list in limited portions spread over time, or even not do it at all until it's scrolled down and/or filtered). Granted, most of those don't improve initialization speed per se, but the main issue here seems to be with UI freezing.

[sharkwouter]

There are a lot of things happening on startup. It creates tiles with image for each game in the library. That will take a while. I can speed up some things, but I'm not sure if it's going to be a completely different experience. Maybe other have some ideas.

Some improvements which I'd like to make still:

• Change the design to only check for updates for a game when you want to launch it.
• Cache some API responses.
• Load from disk first, then ask the API.
• Make the config save directly when updated, instead of polling for changes.

A limitation of python does come into play here too, though. Python is not multi-process by default. Even if you do multi-threading, you're not using multiple CPU cores, you're just allowing you application to do other things while it's waiting for API responses or sleep statements. I'd have to do a very serious redesign if I'd want to load a huge library without a hitch. I can make it a bit faster, but it's not an easy problem.

[LeXofLeviafan]

It creates tiles with image for each game in the library.

Aren't those cached on filesystem? I'm pretty sure it'd be acceptable to at least delay updating them until a bit later. (And if you're talking about rendering, then it's still possible to avoid freezing the UI by not creating all items at once – I doubt it's much harder than splitting the games list into chunks of, say, 100 items each, and setting up the calculation to continue after a short delay if there are more chunks remaining.)

Even if you do multi-threading, you're not using multiple CPU cores, you're just allowing you application to do other things while it's waiting for API responses or sleep statements.

While that is indeed the default, I believe there are ways to sidestep this limitation… such as using the standard library concurrency package.

[LeXofLeviafan]

…Turns out not refreshing after adding every game is a good start :sweat_smile:

[sharkwouter]

Thanks for fixing this @LeXofLeviafan. This bug will be fixed in the next release.