Performance issue with lots of open gpx about viking HOT 4 OPEN

Sadly Viking is not optimized to draw many things and it does it all in software using gdk_draw_*() functions.
It practically draws every point in a GPX file.

Nor is it likely to in the near future. Any change in this area to use techniques such as calculating a simplified polyline and/or try to use hardware rendering would be a significant change (I believe).

What I do is group my tracks in aggregate layers and then use the visibility to selectively control what I want to see.

On my system with 25 of my biggest tracks totalling ~6,500km (~1.5M points), the redraw seems good enough (<1second redraw). Unfortunately some peoples systems have quite slow gdk_draw_*() functions, so even a few tracks displays make it become noticeably slow.

krichter722: Waypoint drawing is especially slow, because by default it will draw the name on the viewport and this text drawing function is relatively slow. One can set the layer properties to not draw the waypoint name.

Also in your example the linked waypoint images won't exist, so each time it will try to find a thumbnail of that image on disk.
As thumbnail creation is performed in a separate thread, it's difficult to differentiate between a thumbnail not created yet, and the thumbnail never going to be available for any particular waypoint.
Again there is a layer property -> Waypoints Images - > Draw Waypoint Images, which can be turned off to make using such data vaguely useable.

from viking.

I'm experiencing similar performance issues. I created the test file
test-manipulated.zip which shows that zooming in and out takes a lot of time depending on how many points are visible on map. I could even observe that the delay in displaying the next zoom step doubles for each zooming out which might indicate the use of a quadratic algorithm (maybe a self-programmed sorting) which should be avoided at all costs. It should be easy to find with a profiler.

experienced with viking-1.6.1-326-g01fad6e8

from viking.

@rnorris Thanks for the insight in the viking internals. Even though I have no knowledge of GDK I can well understand the behavior you're describing based on experience with other rendering frameworks. I also see that the software is advanced and already serving a lot of users. Since you already know the bottlenecks and they apparently already are handled on different threads - or at least some of them - the obvious solution in my point of view is to profit from that and further decouple the software components so that e.g. a request to zoom into the layer first of all only zooms into the layer (which probably also needs to be accelerated by drawing shapes instead of points) and then updates the rest of information (probably a lot, but that doesn't matter) as soon as it's there.

My guess without looking into the code is that there's a component in viking which does way more than it should - which is the absolute minimum in the sense of the 1 component - 1 task.

from viking.

In the past, I also observed important slowness when scrolling while many (several dozens) GPX files were open, in particular when new tiles were downloaded automatically (this was in 2019 with Viking 1.7). But things have recently improved a lot with Viking 1.10 in Debian (but 1.9 has never been packaged), though Viking still hangs a bit when new tiles are downloaded.

from viking.