Skip to content
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

GPXSee is slow to open/view tracks when there are many GPX tracks to load #584

Open
ema-pe opened this issue Mar 15, 2025 · 2 comments
Open

Comments

@ema-pe
Copy link

ema-pe commented Mar 15, 2025

Hi, thank you for developing GPXSee, for me it is an excellent tool for planning bike routes! I mainly use it to visualize my recorded GPX tracks. However, I have noticed a performance problem when loading a large number of GPX tracks. For example, with 166 tracks, it takes about 30 seconds for the application to fully load the GUI, maps, and display the tracks. It appears that GPX files are loaded synchronously and sequentially. I encounter this behavior whether I pass the file paths on the command line or load them using the "Open..." button.

I suggest optimizing the file loading process by implementing asynchronous loading and concurrent loading when there are multiple tracks.

I would like to help since I have some experience with C++, but I'm not familiar with the Qt libraries, so my ability to contribute code is limited. However, I can try and test or do a basic implementation.

@ema-pe ema-pe changed the title GPSee is slow to open/view tracks when there are many GPX tracks to load GPXSee is slow to open/view tracks when there are many GPX tracks to load Mar 15, 2025
@tumic0
Copy link
Owner

tumic0 commented Mar 15, 2025

Yes, the file loading is not parallelized and is thus slow on huge sets. The problem is, the loading is very complicated as there are many file formats and two different groups of files - data files and maps. The "ignore" further errors feature also dnes not help here...

So while parallelize the process is on my todo list and I even have tried multiple times, it always ended with "it's too complicated and not worth it". Working with huge file sets is not the primary usecase of the tool and when it comes to it, you simply wait some time for the files to load. (The performance with that many open files is also not great and you need OpenGL for them to move usably fast).

@ema-pe
Copy link
Author

ema-pe commented Mar 15, 2025

(The performance with that many open files is also not great and you need OpenGL for them to move usably fast).

Indeed I selected the option render using OpenGL to be usable.

So while parallelize the process is on my todo list and I even have tried multiple times, it always ended with "it's too complicated and not worth it". Working with huge file sets is not the primary usecase of the tool and when it comes to it, you simply wait some time for the files to load.

Uh ok, I had no idea this would be so difficult to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants