Improve map rendering speed (expected sub-second)

[ioogithub]

Device: Motorola G7
OS: Android 9 (LineageOS nightly)
Version: 3.3.5 (latest F-Droid version)

When I interact with the map it is very slow to respond. Specifically if I zoom out, the middle tile remains while all of the other tiles around it are black for around 3-5 seconds then it draws the map all at once.

If I zoom in, everything is blurry for 3-7 seconds then it either renders all at once or the elements slowly trickle in.

I can't image this is a limitation of the phone. It is a midrange phone but a current market version. All other software installed acts normally including another map application which zooms smooth and normally.

If I scroll off the screen the map can't keep up either, I see black boxes at the edges, the elements are blurry.

I have tried downloading offline maps, tried changing maps, using online maps, disabled animations, removed all layers and plug-ins except the base map but nothing helps.

I would say it is almost unusable like this.

[dbadura]

I have the same problem with slow rendering.
Android: Android 9 AESP
CPU: Snapdragon 635
No GSF on the phone

Here is a short video
https://gfycat.com/insistentbrownfairybluebird

[brodock]

Same for Huawei P20 Pro.

[sonora]

What you see in the video posted above is the effect of producing a map view from vectorized maps, which is needed for navigation and making all features of the map and their appearance fully configurable. Versus a so called raster or tile map, where you merely cache predefined images and display them on demand. This takes much more storage, is rigid in appearance, but fast.

In OsmAnd you can test by activating the built in Online maps plugin, then under Configure map/Map source select a tile map source. Please note that initially tiles have to be downloaded, so you would see the speed gain only after that.

Regarding the original post: How drastic is the issue reported? Is it like shown in the video, which seems the current state of the art for mid range hardware (including sd cards), or is it a lot worse?

[dbadura]

I think that the issue is the same like on the video.

I also tested the map on snapdragon 632 with normal ROM and the rendering speed was slow.

[dead10ck]

I experience this as well, just as bad as the video posted above, on a OnePlus 7T, which is Snapdragon 855+, top of the line, so it's definitely the app. The performance of the renderer is quite bad.

[dead10ck]

It's also worth noting that online maps don't seem to make much of a difference: https://gfycat.com/giftedspitefularcticfox

So I don't think it's a vector vs raster thing.

[dead10ck]

Is any work being planned on this? This is one of the most common complaints about OSMAnd, next to the router doing weird things.

[brodock]

it's worth noting the iPad version is extremely fast and basically instant, this is really android specific.

[artfulrobot]

Love the app, thanks! But also finding the vector rendering slow. While I understand the benefits of it, I don't understand why the result of the render is not cached. If I scroll left, then right again it seems to have to redraw from the vector again, yet nothing has changed - surely a short lived cache of the render results (5 mins? 30 mins?) would really help?

EDIT: comments below have clarified that it's nothing to do with vector/raster.

[dead10ck]

I really don't think vector vs raster has anything to do with it, it's likely just the implementation. Almost every other navigation app uses vector graphics, and none of them are slow.

[ghost]

Indeed the render speed on a Nokia 5 is on the edge of usability. Regular render times as shown in debug mode of 3-5 seconds makes it appear very laggy. - Latest OsmAnd version an Android 9.

Is there some improvement work going on about this? Can other useful debug information be provided?

[ghost]

I have a recording from my Pixel 2 XL running GrapheneOS (Android 11).
Towards the end you can see the whole map is pure white except a strip at the bottom which fully renders before the rest of the map appears.

Another thing to note is it works nearly perfectly/instantly on an iPhone 8, so I agree with what @dead10ck said about raster vs vector.

Recording: https://archive.cliveptr.cc/github.com/osmandapp/OsmAnd/issues/8370/OsmAnd%20being%20slow.mp4

[artfulrobot]

Yep, @CliveTheSecond details my problem accurately. That video is exactly my experience (I'm on Android 8.1). Please ignore my raster/vector comment.

Sometimes during actual road navigation it can't draw the map fast enough to show me where I'm going, so I've had to go back to Google Maps, and not use the navigation function, which seems a shame. Sounds promising that the IOS version is smoother; makes it sound fixable.

[kaimast]

I can observe this as well on a Pixel 4a with Android 11.

Maybe a short term fix could be to add an option to increase the "view range" that would render tiles that are outside the screen? I also agree that caching would help a lot. Modern phones have a decent amount of (V)RAM, so keeping the tiles in memory should not cause any major problems.

I also suspect that OsmAnd might not use the full concurrency available on modern multi-core systems. Maybe increase the number of threads that render the map tiles?

[fbanning]

I'm experiencing the same problem.

Device: Sony Xperia XA2
OS: LineageOS 17.1 (Nightly 20201210), no Google services
OsmAnd version: 3.8.5 (latest F-Droid)
Map source: Offline

Rendering times are pretty slow (~4-5 seconds) and this gets way worse when scrolling around a bit.

caching would help a lot

Maybe, but there's a case to be made that throwing resources at it would only conceal the actual problem. If it is how others have stated (iOS version rendering very fast) then I would argue looking at this first is a lot more promising.

[joemaro]

Just got a new phone (Xiaomi Poco M4 Pro) which i find pretty fast and performant ... however even though every other app performs much better than it did on my previous phone (Samsung Galaxy S8), Osmand is even slower now ... it takes about a second to render when i zoom out or move ... doesn't matter whether i use relief-shading or not ....
Osmand is THE app for maps, but why is it so slow?

[scaidermern]

Try switching to OpenGL. Enable development plugin, active OpenGL in the settings of this plugin, then restart(!) OsmAnd.

[Redsandro]

Enable development plugin, active OpenGL in the settings of this plugin, then restart OsmAnd.

Helps to move/scroll faster but not to render faster. I have a Xiaomi Mi 9T Pro. When I try "Organic Maps" app I can see what "fast" looks like. I had opened an issue but it was closed. #15269

[scaidermern]

I think it would be a good idea to add to your closed issue that enabling OpenGL fixed only parts of your problem. Otherwise this information get's lost.

[mariush444]

I wonder, maybe the problem is with obf format?
Now there are a lot of data in OSM and maybe obf is to heavy now?
It was good in the past but maybe the are to many details on the map?
e.g. the are many useless: barriers, walkways, passages and so on .... in my area but osmand has to render them because they are in the osm data.

[vshcherb]

Well there is no such problem any more as all rendering is definitely sub-second with v2 opengl on a decent device.

[alexbodn]

Hello @vshcherb
I might be of the last users of v1,
since i had a feeling it is faster.
Please recommend a speedup checklist, with minimal resources consumption, hopefuly.

Thanks in advance,
Alex

[tommycrock]

I'm interested in what's considered decent as I also use v1, opengl has been unusable for me on a Samsung galaxy s10e

[mariush444]

I have a headache and go to doctor and doctor says "no, you haven't"

sometimes I get the impression that osmand team don't use its own product in the real world.

[Redsandro]

I'm hoping a developer will be intrigued by the rendering speed of Organic Maps (open source), because there is a world of difference between sub-second and near-instant and it adds up when swiping around to look for something.

[YBerd]

On my galaxy s9+ rendering speed increased significantly after deletion of downloaded maps except for current region. It may indicate some inefficiencies in data lookup part.
Also I kindly ask to check rendering style rule lookup performance. It was the longest part in old java rendering (see my older comment with proposed speedup technique), maybe new renderer can benefit from similar approach.

[tommycrock]

Interesting! I deleted most other maps and it made a big difference. I deactivated sea marks, depth, world map overview and rendering was usable with opengl. But surely it shouldn't be like this when there's no relavant data there?

[scaidermern]

On my galaxy s9+ rendering speed increased significantly after deletion of downloaded maps except for current region.

That's strange. Same device here. I don't notice any difference in rendering speed with one map enabled vs all of them (14 maps / 8 GB).

However, usually I keep just the current region enabled nevertheless because it improves search speed, I think.

[rlaggren]

I just got an S22 Ultra with 12GB RAM (couldn't find 16GB anywhere but Asia). For this app, I think RAM may be one of the most important resources. On my phone, OsmAnd runs ok, renders ok. And I have the whole lower 48 of the USA loaded. For my use case, that's important - I travel coast to coast couple times a year taking different routes and I don't want to find myself sans map in the wrong place (no connection). Not sure if I have the opengl option enabled on this phone - I didn't see anything that looked like that setting, even under "Developer". I know the dev team is stretched but there _must_ be bottlenecks in the normal processing and they can't be _that_ hard to find. (?) Hopefully. And once listed, I really think they deserve some priority because OsmAnd was simply not usable on my previous phone. Maybe it's better with what's selling mass market today, which seems to be 8GB. Just putting my vote in here to up the priority of "optimizing", or more than that, the element creation and rendering engine. I have probably one of the most powerful platforms out there and OsmAnd runs... ok. Think of rest of those travelers... Just sayin'. Rufus

…

On 1/30/23 14:23, Mars Yush wrote: I have a headache and go to doctor and doctor says "no, you haven't" sometimes I get the impression that osmand team don't use its own product in the real world. — Reply to this email directly, view it on GitHub <#11961 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHWKOLMTLNI6QLQ2HRCKDCLWVA5PPANCNFSM47BMWFRQ>. You are receiving this because you commented.Message ID: ***@***.***>

[scaidermern]

Not sure if I have the opengl option enabled on this phone - I didn't see anything that looked like that setting, even under "Developer".

In the current version this setting is located at Settings / OsmAnd settings / Map rendering engine.

[Redsandro]

4.2.7 -> Plugins -> OsmAnd development -> Settings -> OpenGL Rendering
4.3.5 -> Settings -> OsmAnd settings -> Map rendering engine -> V2 OpenGL

[mmacura311]

my 2 cents - with the old engine it was very visible that there was little to no caching of the generated map. I swiped left, map was rendered, swipe back right to where I was before - map was rendered again. With the opengl rendering it is much faster but still noticeable eg on POIs on the map. This would probably not solve the issue, but would reduce the frustrating factor when searching for something on the map, swiping around and the app keep re-rendering again and again same areas.

[Redsandro]

I swiped left, map was rendered, swipe back right to where I was before - map was rendered again.

Yes exactly, hold a point and repeatedly draw an "O". OsmAnd is constantly rendering. Do this on any other app and everything is already rendered and cached. Or a more real life example: Quickly swipe across a semi-familiar map towards a place you're trying to find. OsmAnd only starts drawing for about a second once the map view almost stops moving, adding about a second delay before you can decide the direction of your next swipe. This impedes manual searching, so I use another app for that. Other apps start rendering the tiles immediately when you let go (i.e. finish the swipe) because the swipe vector mathematically predicts all the tiles you will be seeing. No need to wait for them to scroll into view before rendering. No need to delay rendering until it becomes an obstruction to the user.

These were point 2 and 3 in my issue report, which was closed by @vshcherb as deprecated by OpenGL rendering. Even though myself and you and others report that this is still an obvious issue, only less annoying because the late rendering and unnecessary re-rendering takes less time now. But it's still late and unnecessary, it still adds an extra second every time.

Admitting, accepting, identifying and listing all the causes for the comparatively slow rendering is half the solution. Everyone understands if a volunteer developer doesn't have time or motivation to fix those causes, but it appears as if we're still debating for recognition. Ignoring or disregarding these issues is just frustrating.

On the other hand, it must be frustrating for the devs to pour your heart and soul into an app, and still have a list of issues and complaints from users. I know it can be frustrating but also rewarding from my time maintaining the security releases of two LineageOS devices when so many people report issues but so few people help out. I think OsmAnd suffers from first-mover disadvantage, because it was really cool really early. Now there are probably some legacy design decisions preventing it from keeping up with more modern apps, and it may take a disproportionate amount of work to remedy this because of it. Keeping tiles in cache however does not seem like a disproportionate amount of work.

For what it's worth, I gave compliments by purchasing OsmAnd+, so I feel less shy when persisting on the recognition for these issues of rendering speed.

[vshcherb]

Your issue was reported on legacy rendering and there was no further analysis on new rendering.

• Cache is something possible to introduce but mostly not needed
• Rendering of text disappears between zoom and the problem is recognized, at least it's in a process thinking
• Intermediate zoom will be introduced this year, so it should change how interaction looks like

Also with recent update of 3D maps and recent release we encounter quite a big list of open issues related to large amount of tracks and how interaction looks in 3D, so it's quite a huge progress going on right now with rendering.

For example, only in 4.3 we've finalized smooth animation during navigation that supports 60-120 FPS and moves gently on turns and on straights. Initial public release of opengl hapened just Jun 2022 (4.2), so I'm pretty confident that there is a huge progress and lots of things going to improve.

[Redsandro]

I'm very happy to hear intermediate zoom is on the road map!

Your issue was reported on legacy rendering and there was no further analysis on new rendering.

I think there has been a misunderstanding. I reported still seeing 3 out of 5 problems that contributed to the main issue after trying the new rendering. I can separate the problems and create separate issues and make new video recordings if it would be helpful.

[vshcherb]

Even if we don't implement it or decide not to do, it's better to have it tracked as open issue if it still exists and preferably as new, so we refer to the new state without legacy comments.

[Redsandro]

@vshcherb I've created these for now:

• Display recorded tracks slows down map, even when not near viewport #16390
• Tiles get redrawn all the time, even if they were drawn moments ago. #16391
• Offline Rendering: to speed up displaying tiles, introduce cache or prerender tiles  #16392

[sonora]

Indeed, IMHO caching should always be a consideration, regardless of how powerful or fast we may think the engines are or could be...

[alexbodn]

following this conversation, i switched to render engine v2, and admit it's working better than v1.

thanks a lot

[rlaggren]

It's great to hear your words that there is much awareness and action around rendering and moving forward. Thank you devs for all your efforts. Cheers, Rufus

…

On 1/31/23 12:05, vshcherb wrote: Your issue was reported on legacy rendering and there was no further analysis on new rendering. * Cache is something possible to introduce but mostly not needed * Rendering of text disappears between zoom and the problem is recognized, at least it's in a process thinking * Intermediate zoom will be introduced this year, so it should change how interaction looks like Also with recent update of 3D maps and recent release we encounter quite a big list of open issues related to large amount of tracks and how interaction looks in 3D, so it's quite a huge progress going on right now with rendering. For example, only in 4.3 we've finalized smooth animation during navigation that supports 60-120 FPS and moves gently on turns and on straights. Initial public release of opengl hapened just Jun 2022 (4.2), so I'm pretty confident that there is a huge progress and lots of things going to improve. — Reply to this email directly, view it on GitHub <#11961 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHWKOLKAUO5JKEIVRIDCLQ3WVFWBZANCNFSM47BMWFRQ>. You are receiving this because you commented.Message ID: ***@***.***>

[ericJrdn]

very nice improvement

[katomihaivalergit]

NEW: I did implement the new map renderer from SDK 18+ and improved my maps, now 5x faster & smoother. https://developers.google.com/maps/documentation/android-sdk/renderer

Add this to your build.gradle
implementation "com.google.android.gms:play-services-maps:18.1.0"

In your app (MainActivity)
import com.google.android.gms.maps.MapsInitializer;
import com.google.android.gms.maps.MapsInitializer.Renderer;
import com.google.android.gms.maps.OnMapsSdkInitializedCallback;

class MapRendererOptInApplication extends Application implements OnMapsSdkInitializedCallback {

@OverRide
public void onCreate() {
super.onCreate();
MapsInitializer.initialize(getApplicationContext(), Renderer.LATEST, this);
}

@OverRide
public void onMapsSdkInitialized(MapsInitializer.Renderer renderer) {
switch (renderer) {
case LATEST:
Log.d("MapsDemo", "The latest version of the renderer is used.");
break;
case LEGACY:
Log.d("MapsDemo", "The legacy version of the renderer is used.");
break;
}
}
}

[mariush444]

good discovering, congratulation

[sphakka]

Hi,

I don't know what the development state is now, but, with my old FP2 (unfortunately stuck on LineageOS 18.1, though fully degooglified and kept in the lightest and sanest state as possible), the performance has been slowly degrading (it was great 2-3 years ago) to the point where the app is almost unusable -- not much difference with engine v1 vs v2. See also other reports with newer devices.

As my phone is rooted and I have full control of it, I wonder if there's any system-level tweak I may try.

Cheers,

Marco

[scaidermern]

You can try to improve map rendering speed by disabling features that are less important. 3D relief, terrain, contour lines.
Also, only enable maps you really need. Check that you don't have overlapping maps installed.

[mariush444]

If you don't need above features just go back to 4.5.10 or even 3.5.7.
Stabile, efficient, less bugs.

[sphakka]

@scaidermern, @mariush444, thanks for the tips!

[jm355]

I was playing around with this and comparing osmand to organic maps and magic earth, I think what organic maps and magic earth might be doing is caching certain parts of the map, and then only rendering details like labels, icons, etc as you move around. So the most fundamental layers like roads always quickly display as you pan around, but the other things take a similar amount of time to load as osmand.

Maybe osmand could do something similar, like cache an extremely stripped version of the map in an area that's, say, 200% bigger than the screen, ready to display instead of the gray grid, and then let all other details on top of that render in their own time, when visible?

[scaidermern]

The first step is to identify which parts of the map rendering process are the slow ones. Then start to optimize them.

[jm355]

That's one strategy. The strategy I'm proposing is identify which parts of the map are absolutely essential to avoid displaying the gray grid (e.g. background color, roads), make sure that the user can pan around and always see those essentials without running into gray grid, and then let the "non-essential" parts load with lower priority.

I agree that other parts should be optimized too, whether via the way you're talking about or a blanket "optimize all parts" approach, but I think prioritizing essentials like I describe makes sense both now as a sort of bandaid to other inefficiencies, and I think it would be worthwhile even if all the other parts are totally optimized.

[mikehgentry]

I put in a F/R for more or less this, #18188

[mariush444]

Casheing is not always the best solution because of memory. Osmand needs much memory for routing and additional cashe (appart to existing) can kill cheaper and older phons. There are still users going with Andro 7/8.
The 1st step is to optimalize code source.