QMS "freezing" on restart due to project containing long distance route

[JFritzle]

Describe the bug

When restarting QMS after having created a long distance route with router,

• QMS may be unresponsive and seems frozen for a long time
  (using my example project in my environment more than 60 seconds!)
• QMS may show unsuitable message during that time,
  leaving the user unclear about what is currently going on or if something is still going on at all

What have you done to circle down the problem?

To Reproduce

1. Import attached GPX example file From Hamburg to Munich.gpx
2. Calculate route using BRouter with profile car-eco and alternative original
3. Close QMS
4. Restart QMS
5. See issue described above

Expected behavior

At least, I had expected that QMS message window shows a suitable message telling what is going on.

At best, I had expected that QMS does not only save route's endpoints and recalculate route at restart. But saves calcaluted route at closing QMS making recalculation unnecessary at restart.

Screenshots

Screenshot taken after restarting QMS while app is unresponsive and seems to be frozen for a long time ...

... pretending that tile server (in my case local Mapsforge tile server) is unresponsive not sending requested tiles.

Screenshot taken quite a long time later after QMS has become responsive ...

... showing that frozen state was not due to an unresponsive tile server but due to recalculating long distance route at restart.

Attachments

From Hamburg to Munich.zip

Tracebacks

Desktop

• OS: at least Windows
• QMapShack Version: at least current version 1.19.0
• Window Manager: -

Additional context

[kiozen]

At best, I had expected that QMS does not only save route's endpoints and recalculate route at restart. But saves calculated route at closing QMS making recalculation unnecessary at restart.

That's also my expectation.

Calculating the route takes several seconds on my machine (15s). Restarting QMapShack displays the route without re-calculation. 🤔

A general design flaw of QMapShack is that progress dialog. And the fact that most of the stuff is done in the main UI thread blocking the event loop. The progress dialog bypasses this problem by operating the event loop. However that introduces re-entrancy via the back door. Usually this is not that much of a problem. However at startup quite a lot of stuff is scheduled and that leads to funny behavior.

The proper way is to do stuff in threads. I analyzed the code just a couple of weeks ago and came to the conclusion that this would be re-writing huge portions of the code. In fact workspace, map and DEM lists would need to be rewritten to follow a proper data/view model etc. An interesting task but way beyond my time budget.

Long story short: if you can circle down the exact root cause in the code, we might be able to find a workaround.

[eyzdh]

Just the Calculate Time: On my Macbook it takes 10s and Routino was 5s.