Zooming performance issues when multiple tracks are selected

joeloc shared this problem 9 years ago
Solved

Locus zooms very fast now in general. However, when multiple tracks (or map items) are selected, the zooming performance suffers a lot (eg from a >50fps down to 3fps). That also happens when the selected tracks are thousands of miles away and not even close to being visible.


The scrolling performance does not seem to be affected by selected invisible tracks. Only zooming becomes slow.


Tried with latest 2.5.4.2 testing version.

Replies (8)

photo
0

hmm currently I see no simple solution for this. One problem (probably mainly in your case) was! slow zooming in high zooms on huge RMAP maps. This should be fixed in next version.


When you zoom, all tracks, visible or invisible on screen, have to be recomputed to new map projection of current zoom, so it takes some time. (they have to be recomputed because without this, I don`t know if they`re visible in new zoom or not) Unfortunately I`m doing this in main application thread so it lower performance if you have a lot of tracks. It should be much faster now then it was around a month ago, but I know it`s still not best

photo
0

I understand. The problem is most visible when using pinch&zoom obviously, where Locus can be either superfast or superslow and there is no apparent reason for it on screen. For example, I enabled all camino santiagos of Spain as mapitems last week and then completely forgot about it. I was confused for several days why pinch&zoom in Germany was slow.


Recomputing tracks in another thread might be ideal. Immediately stop & restart that sub-thread with new values when the user keeps zooming. I know this is not an easy solution, programmingwise.


Another idea, less elegant but maybe simpler to implement: While pinch-zooming is in progress, you only recalcultate the tracks that were on screen when the pinch-zooming operation started. Only when the user stops pinch-zooming (or pauses it for a moment), you recalcuate all enabled tracks.


The second suggestion means that we would always have speedy pinchzooming, but newly visible tracks would only appear on screen when pausing for a split second or stopping pinch-zoom. Sounds reasonable imho.


Oh... also... you do not need to recalculate non-visible tracks at all when zooming in! New stuff can only appear when zooming out.

photo
1

After thinking about it some more, I apparently dont understand another thing: Every track stores its bounding box (min & max latitude/longitude) somewhere I assume? It should be a matter of microseconds to check this bounding box against the current screen and simply DO NOTHING when it is outside.


Just flag the track data as "unclean/needsrecalc" on zooming and do whatever needs to be done when the track comes into view. Not earlier.


Not only should that speed up Locus a lot, but it will also save plenty battery power by preventing many unnecessary calculations. Because when you pinch&zoom with off-screen tracks now, all the things you calculate are simply invalidated in the next millisecond when the users keeps zooming.

photo
1

yes I was also thinking about correct checking of bounding box. It`s also not so simply but I think it should work. I`ll check it to next version

photo
2

Two years have passed meanwhile and zooming performance is still a major issue: Have a few dozen tracks enabled in Peru and Locus slows to a crawl while pinch & zooming around in totally unrelated parts of the world, eg. in Germany.

photo
2

ps, not sure why this topic is marked as "solved". maybe it was solved once, but it certainly isnt anymore. tried with latest pro & testing and 40 peruvian tracks and zooming around germany on either rmap or vector maps:


invisible tracks disabled = supersmooth pinch & zoom, 30 fps and better.

invisible tracks enabled = around 1 fps, horrible usability.

photo
2

Hello Stephan, welcome back :).

Performance always depends on amount of visible trackpoints on a map. If your tracks has, let's say, all together more then 30k points, performance should go down a lot ...


EDIT: ah, I missed your previous post. Your tracks aren't visible on screen (not even a part of them) and zoom is still slower? Hmm should not be ... I'll check it thanks. Two years back are two years and I do not even remember what optimizations I finally did ...

photo
1

The number of visible track points is always zero, nothing is on screen. Not even close to being visible, Peru is quite far from Germany :-).


I just tried to export my peru track folder to attach as an example, but Locus apparently fails on that. 41 tracks are selected, but the zip file that Locus creates only holds 10 tracks after export. Weird... looks like another bug?


Anyway... i packed the gpxes into a zip manually... see attached file.

photo
2

to follow up on the export problem: i select all 41 tracks in my peru folder and export them in locus: 41 single gpx files are created. so far so good.

however, when i enable "send data" in locus export window, Locus creates a zip file ("export_12345.zip") and passes that on to whatever app i select. This zip file does NOT contain the 41 exported gpx files, but only around 10 of them.

photo
1

Thanks Stephan, I'll check all and let you know, probably tomorrow ...

photo
1

Hmm, I was worried that this may happen.

1. I've imported all your tracks. It seems to be all together around 5Ok points. Because even will all tracks visible, pinch zoom was quite smooth, I duplicated all tracks. With almost 100k points, I think I'm at about 10fps. Well, still quite good I think.

I exactly see where is a problem in my code and I'm aware of possible improvements. Whole handling of map items should be rewrote. It deserve after almost four years without major change. There is also second issue connected to this - incorrectly placed points and tracks from network link when you move map during loading. I'm more and more pushed to invest few days to this, so soon or later, I'll have to ..

2. unfortunately export and sharing tracks works fine for me. May you try to create for me next time a log right after export? Maybe there should be any problem. Thanks a lot!


EDIT: btw. as a small workaround, try to use +/- or hardware (volume) buttons for zoom. It will be a lot more faster as Locus needs to re-initialize all tracks just once (one change of zoom), except a lot more times (lot more change of zooms during pinch zoom).

photo
2

10fps with double my tracks? my note 2 is probably too old :). i am really at only 1 or 2. it seems quicker if you scroll further out and gets slower when you're further in, like at zoom 15 and closer. when i play around a bit there, sometimes i even get this android message "Locus is not responding... wait|close".


I dont expect Locus to handle 40 visible tracks in a microsecond. But offscreen tracks really shouldnt have an impact on performance at all, no matter if its 100 or 100.000 total points. Apparently the "bounding box checking" from two years earlier in this thread doesnt work. I kept wondering why Locus was so sluggish after coming home from my last trip overseas until I discovered a few enabled tracks in some track folder on the other side of the planet :).


Glad you're looking into a rewrite of this. Maybe put it into a separate thread as well while you're at it... yes... I know this is hard... :-). It doesnt matter at all when stuff appears asynchronously a bit later after a pinch&zoom. But it matters majorly if any calculation whatsoever blocks the next pinch&zoom even for just a tenth of a second. That kills the whole slick and smooth user interface feeling imho.


Good luck :-).


Will try to create a log for the failing zip export packing... maybe it's some out of memory issue...if you export & send data the 40 tracks, the zip really has all of them? Weird.

photo
2

I found the reason for the export failure. My peru track folder contains (for whatever reason) three tracks with the same name ("Conococha_Cajatambo_Oyon"). Now when Locus exports and ZIPs, there is a

System.err at java.util.zip.ZipOutputStream.putNextEntry Entry already exists.


Not sure what the proper course of action for Locus here is, but silently missing out on all other tracks in the folder sucks. You could skip over the error and continue with the following tracks... or add a number to the name and try again... no idea.

photo
photo
2

Still unsolved. Import http://www.adventurecycling.org/default/assets/file/KML/overview/ACA_Network_03_26_15.kmz and then move back to your home town and zoom to your favorite bar. Sooooooooooooo slow :).

photo
2

Slowdown doesnt depend on number of enabled tracks apparently, but only on total number of visible track points. 1000 tiny tracks with 50 points each slow Locus down just as much as one huge track with 50.000 points.


That seems to indicate that Locus iterates through each and every single track point on each zoom (even during pinch & zoom).

photo
2

mainly during pinch zoom! I never said it is already fixed ... but thanks for a track, I'm anyway worried it is not so simple to fix it quickly ... suggestion is not to use pinch zoom, but rather UI buttons ...

photo
2

> I never said it is already fixed


Indeed not. But even after two years, I haven't given up hope :-).

photo
1

I still gather the courage to completely rewrite whole system that draw points/tracks/etc. on the map ... anyway it's more and more needed, because this is not the only problem/limitation of my old system ...

photo
2

I hope the rewrite will do it's work in a separate thread... good luck in finding the courage!


I also need "courage" to face at least one "Locus doesnt respond/Wait/Close" message per day :).

photo
1

It should be little bit better (cca 10-20%) in latest 3.8.2.3 version. But it is really best what I can get from current system. But I think that time of rewrite is quite close :)

photo
photo
2

If you promise to use separate threads for everything remotely "expensive", I will gladly wait another two years... :-)

ac8cac7e9044f829296344a8558f6fbb

photo
1

Hello Stephan,

very old topic with one very important task: performance improvement.

Over the last years, in the app were many changes regards how items are drawn on the map. Performance is currently not a major problem I believe, but it is a permanent task that is always worth the time. With this, I'm closing this old task. Thanks for the contribution and necessary pushes!

Jiří M. aka Menion

Leave a Comment
 
Attach a file