Major slowness on high zooms
Locus again surprises with weird and rather horrible slowness even on todays fastest devices :-).
Have a few dozen tracks enabled (reasonably sized, not like 10000 points each, but that should not matter anyway) on the island of Gomera. Things are "fine" on "normal" zooms around 14 or some such. But beware... if you try to look into a beach to find a place to sleep (eg google satellite map zoom 20), everything slows down to an absolute CRAWL... like 1 fps scrolling. That's even more surprising since none of the enabled tracks are anywhere close to being visible. Locus only needs to show the map... nothing else... and fails spectacularly... speed wise. 1 fps with 100% cpu isnt fun.
Is it really necessary to process every single point of every single track on every scroll op? That really smells like a bug... I would think checking a single rectangle per track for visibility should be sufficient.
Tracks file attached for testing.
The same problem 
Slow down does not happen without enabled tracks. It is definitely related to track parsing at high zoom levels. Locus version: Latest Pro.
Slow down does not happen without enabled tracks. It is definitely related to track parsing at high zoom levels. Locus version: Latest Pro.
The slow down is extreme... just tested with only 10 enabled tracks (and only 100 points each). Each zoom level higher just about halfs(!) the speed. At 20 you're practically dead. Higher zoom levels are unusable at the moment... 50 fps at 16 will give you 1.5 fps at 20.
Happens with pixel maps and vector maps and online maps alike... as soon as you have tracks enabled, you're f*cked. Galaxy Note 4 on 5.1.1 (CM 12.1).
The slow down is extreme... just tested with only 10 enabled tracks (and only 100 points each). Each zoom level higher just about halfs(!) the speed. At 20 you're practically dead. Higher zoom levels are unusable at the moment... 50 fps at 16 will give you 1.5 fps at 20.
Happens with pixel maps and vector maps and online maps alike... as soon as you have tracks enabled, you're f*cked. Galaxy Note 4 on 5.1.1 (CM 12.1).
Same problem with Locus free test version. Higher zooms are pretty much dead when only a few tracks are enabled. I am sure this is a new bug... Locus did not have this problem last year. High zooms were just fine.
Same problem with Locus free test version. Higher zooms are pretty much dead when only a few tracks are enabled. I am sure this is a new bug... Locus did not have this problem last year. High zooms were just fine.
I just found the reason for the massive slowdowns. It only happens when the enabled tracks have a custom display style other than a simple line!
Simple line: speed is totally OK, 50fps even at high zooms.
Dotted line: High zooms are dead in the water... 1fps and less.
Very strange, since not a single pixel of the tracks is actually visible on screen. There must be a serious bug with Locus handling of track styles somewhere.
I just found the reason for the massive slowdowns. It only happens when the enabled tracks have a custom display style other than a simple line!
Simple line: speed is totally OK, 50fps even at high zooms.
Dotted line: High zooms are dead in the water... 1fps and less.
Very strange, since not a single pixel of the tracks is actually visible on screen. There must be a serious bug with Locus handling of track styles somewhere.
Hello joeloc,
thanks for a trust in my algorithms. Yes, Locus is testing bounding boxes of every track before real drawing, yes I've just tested it and it really works correctly and yes you are correct and drawing same track with other style then a simple line (so with any effect) cause major slowdown.
I'm testing it and moving with map on zoom 20 at coordinates 28.322, 016.693 cause drawing of five tracks (because some of them are really large and their bounding box cover also this area) even that only a single track is visible. Anyway exact measurement of CPU usage display stuck on one function : Android.paint(). So this slowdown is directly in android code that draw a path.
Only solutions here should be reducing drawing of four lines that are not needed in that moment and also separating visible path into more segments and drawing just a part of this line. Both tasks: a lot of work to make it correctly.
Nice discovered anyway. I'll keep this in mind when I'll do something around whole drawing system of map items (as I already plan for maybe few years).
Hello joeloc,
thanks for a trust in my algorithms. Yes, Locus is testing bounding boxes of every track before real drawing, yes I've just tested it and it really works correctly and yes you are correct and drawing same track with other style then a simple line (so with any effect) cause major slowdown.
I'm testing it and moving with map on zoom 20 at coordinates 28.322, 016.693 cause drawing of five tracks (because some of them are really large and their bounding box cover also this area) even that only a single track is visible. Anyway exact measurement of CPU usage display stuck on one function : Android.paint(). So this slowdown is directly in android code that draw a path.
Only solutions here should be reducing drawing of four lines that are not needed in that moment and also separating visible path into more segments and drawing just a part of this line. Both tasks: a lot of work to make it correctly.
Nice discovered anyway. I'll keep this in mind when I'll do something around whole drawing system of map items (as I already plan for maybe few years).
Maybe the draw function has a return value that tells you if any pixels were actually drawn? If so, an easy fix could be: if special styles are needed, render a "test" line without special styles first at opacity 1%. If result tells you that pixels were drawn, render the real thing with styles.
Maybe the draw function has a return value that tells you if any pixels were actually drawn? If so, an easy fix could be: if special styles are needed, render a "test" line without special styles first at opacity 1%. If result tells you that pixels were drawn, render the real thing with styles.
An even simpler fix that might work for other cases as well: Measure the time required for rendering. If its above 0.2s and zoom is above 16, render without styles.
I am just brainstorming to "rescue" the styles somehow... because right now, they can hardly be used if you need detailed zooms.
An even simpler fix that might work for other cases as well: Measure the time required for rendering. If its above 0.2s and zoom is above 16, render without styles.
I am just brainstorming to "rescue" the styles somehow... because right now, they can hardly be used if you need detailed zooms.
And the simplest suggestion of all:
if (zoom>configfile.maxstylezoom)
styles=0;
Obviously only until the major display engine rewrite that's pending since a few years but will happen for Christmas: OpenGL3DLocus :)
And the simplest suggestion of all:
if (zoom>configfile.maxstylezoom)
styles=0;
Obviously only until the major display engine rewrite that's pending since a few years but will happen for Christmas: OpenGL3DLocus :)
Menion... did you fix styles meanwhile? I just tried again and the major slowdown at zoom 20 is more or less gone. Even complex styles (arrows etc) render reasonably quick now.
The slowdown to crawling speeds happens much later now... like at zoom 20/2000%. Since thats irrelevant for day2day use, I guess this topic could be marked as solved.
If you didnt change anything, maybe it was fixed by some Android update. I installed a few new CM12 ROMs recently.
Menion... did you fix styles meanwhile? I just tried again and the major slowdown at zoom 20 is more or less gone. Even complex styles (arrows etc) render reasonably quick now.
The slowdown to crawling speeds happens much later now... like at zoom 20/2000%. Since thats irrelevant for day2day use, I guess this topic could be marked as solved.
If you didnt change anything, maybe it was fixed by some Android update. I installed a few new CM12 ROMs recently.
I did optimizations everytime I find during own work some unexpected problems. So during last weeks, I remember I've improved some testing of bounding boxes, some initialization of coordinates, but major problem (converting of track coordinates right after zoom directly in UI thread), is still there. Anyway if some changes helped here, or if it was fixed by any updated in CM, very good to hear it!
On second side, because if I remember correctly, slowdown was caused by "invisible" tracks in second side of earth, maybe you just hide these tracks :). Anyway I'll close this topic as solved, because no matter how situation is now, I'm still and everytime working on never-ending improvements :)
I did optimizations everytime I find during own work some unexpected problems. So during last weeks, I remember I've improved some testing of bounding boxes, some initialization of coordinates, but major problem (converting of track coordinates right after zoom directly in UI thread), is still there. Anyway if some changes helped here, or if it was fixed by any updated in CM, very good to hear it!
On second side, because if I remember correctly, slowdown was caused by "invisible" tracks in second side of earth, maybe you just hide these tracks :). Anyway I'll close this topic as solved, because no matter how situation is now, I'm still and everytime working on never-ending improvements :)
Replies have been locked on this page!