(Bad) Map rendering performance

[Harry van der Wolf]

Hi,

Since version 1.5 or 1.6, when the double-layer rendering was introduced (the extra zoom possibilities and adjustable map magnifier), I have always complained about the rendering speed and I was completely happing with the "old" autozoom functionality . And more people complain about the rendering speed.

Sometime around October-December I responded on such a mail that roads-only maps render much faster than full maps.  Xmd5a2 (Leonid), who does most of the map stuff (and he does that very well) responded on my remark that there is only a 15% margin or so in rendering speed between roads-only maps and full maps. At that time I was hardly spending time on OsmAnd so I did not react.

However, Yesterday I spend some time (and not a quick 1 minute) on it comparing both map types with debugging switched on showing the "Display Rendering performance". This shows you the search time and rendering time.

The search time does not vary much. I assume due to the fact that the data as such is all nicely indexed.

roads-only:  350-500 ms

full maps: 450-600 ms

However, map rendering makes a very big difference. Of course due to the sheer amount of extra data that needs to be rendered:

roads-only maps: 350-650 ms (with an occasional spike to 1300-1500 ms)

full maps: 1350-1900 ms (with an occasional spike to 2700-2900 ms)

This is also my personal experience when navigating (if I occasionaly use OsmAnd for car navigation) and simply looking at how fast the screen is built up and where "gray" triangles/rectangles are appearing as OsmAnd can't keep up when the screen auto-rotates on road curves/bends.

This is on a Samsung S5 mini quad-core 1280x720 phone with 1½ GB memory and a class-10 32GB SDcard. It is not a high-end phone (anymore) but definitely not a low-end phone either.

If I compare OsmAnd rendering speeds with other nav apps, OsmAnd falls back dramatically to all other apps.

Anyway:

The frontpage on Osmand.net mentioned late December/early January that priorties for 2016 were among others rendering performance (next to route calculation performance and 3D (2½D) rendering).

I'm really hoping these priorities will be realized as I still am a great Open Source believer and do think OsmAnd is a great project, but currently I'm using another app for car navigation.

Harry

[Hugo Barrocas]

I have a Bq Aquaris E6 octacore, and it doesn't matter, it also render a bit slower than desired, very near to a quad-core I had before.

And I remember having used slow single core phones running Osmand with 512mb of Ram, a long time ago...

I guess Osmand uses only single-core performance, it doesn't take advantage of the multi-core processing.

With Osm-live updates, it gets even slower.

But I do use it daily for car navigation and Osm adding/editing of POI, and recording notes for later.

[Harry van der Wolf]

You are right w.r.t. to OsmAnd using only one core.

That was another point for 2016 as I remember now.

On one of my older phones performance is comparable as the resolution is only 800x480: 2.4x times as less pixels to render.

Andonly one core doing the work.

However, that one had only 512MB memory which made calculations of longer routes impossible. At that time that was for me a real showstopper: Claiming that the route calculation is the best and accurate there is, and add the same time having to add waypoints thereby completely ruining this perfect route algorithm. I still don't understand that design flaw.

It makes OsmAnd in one step the worst navigation app for routes over 200-300 km.

--
You received this message because you are subscribed to the Google Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osmand+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Carles Pina i Estany]

Hi,

On Mar/28/2016, Harry van der Wolf wrote:

> If I compare OsmAnd rendering speeds with other nav apps, OsmAnd falls back
> dramatically to all other apps.

this is the biggest reason that I don't always recommend OsmAnd to
friends... because it is very slow to render!

I wish that the priorities would be to improve the speed and fix bugs
(I find it a bit difficult to use) before adding new features...

--
Carles Pina i Estany
Web: http://pinux.info || Blog: http://pintant.cat
GPG Key 0x8CD5C157

[Stephan75]

I already stated months or years ago that maybe we need a bit of profiling for Osmand app.

Although I never did that on my own, there should be a method how to measure where most time and memory is needed when doing map display or route calculation in the app.

Or find the reason why map creation process needs really so long even on a i7 CPU desktop PC.

Is there anybody able to find out a tool fitting to Osmand's sourcecode?

see https://en.wikipedia.org/wiki/Valgrind

or

https://en.wikipedia.org/wiki/Profiling_(computer_programming)

or

https://en.wikipedia.org/wiki/List_of_performance_analysis_tools

Stephan

[Carles Pina i Estany]

And perhaps someone from the project could setup bounties if they need
some financial support. I like the project and maybe a few people could
help a little bit in exchange of speed improvements :-) (I would do).

On Mar/30/2016, 'Stephan75' via Osmand wrote:
> I already stated months or years ago that maybe we need a bit of profiling
> for Osmand app.
>
> Although I never did that on my own, there should be a method how to
> measure where most time and memory is needed when doing map display or
> route calculation in the app.
>
> Or find the reason why map creation process needs really so long even on a
> i7 CPU desktop PC.
>

> *Is there anybody able to find out a tool fitting to Osmand's sourcecode?*

>
> see https://en.wikipedia.org/wiki/Valgrind
> or
> https://en.wikipedia.org/wiki/Profiling_(computer_programming)
> or
> https://en.wikipedia.org/wiki/List_of_performance_analysis_tools
>
> Stephan
>
>
> Am Mittwoch, 30. März 2016 16:27:07 UTC+2 schrieb Carles Pina Estany:
> >
> >
> > Hi,
> >
> > On Mar/28/2016, Harry van der Wolf wrote:
> >
> > > If I compare OsmAnd rendering speeds with other nav apps, OsmAnd falls
> > back
> > > dramatically to all other apps.
> >
> > this is the biggest reason that I don't always recommend OsmAnd to
> > friends... because it is very slow to render!
> >
> > I wish that the priorities would be to improve the speed and fix bugs
> > (I find it a bit difficult to use) before adding new features...
> >
> > --
> > Carles Pina i Estany
> > Web: http://pinux.info || Blog: http://pintant.cat
> > GPG Key 0x8CD5C157
> >
>

> --
> You received this message because you are subscribed to the Google Groups "Osmand" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to osmand+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Harry van der Wolf]

Warning: long mail ahead :)

Part of the problem is the huge amount of map data.

If you compare OsmAnd to other nav apps, you see that the amount of map data and details is the highest of all (and so is the size).

Here Maps, Mapfactor Navigator, Navmii, Google Maps: not one of them contains that much detail. Google Maps as such does but not when in navigation mode.

Maybe the OsmAnd code is relatively well optimized already but if you need to display/render such an extreme amount of extra data you will never be able to do that fluently unless it is on a high-end phone and maybe when using multiple processors.

I have multiple times asked for a render mode that was as clean as possible for car navigation because all this unnecessary data only distracts your from what is really important. That is also exactly what the other nav apps do: They show you what you need to see while driving. All those "stupid" details are unnecessary. (Whereas you want to see those details while cycling or hiking).

The roads-only roads do exactly this and they are much faster. If you compare these roads-only maps with e.g. Mapfactor Navigator and Navmii, these contain less data, but it's not a big difference as these maps are quite "empty" as well.

If you compare those roads-only maps with Here maps, they are the same. Here Maps shows you roads and some areas if they are big (forests, farm land, wild land, but not every backyard garden of every house)

Maybe the fact that the others show (can show) fluent maps is because they don't need to show that much data.

Full maps contain routing, map, poi, address and transport data.

The "new" roads-only maps contain minor map details and routing, poi and address data. The old roads-only maps only had the "routing" data and no map data at all. The rendering mechanism was that roads would be displayed anyway based on the routing data, not because they were available as map data.

Maybe a simple switch (check box) would already be sufficient to make OsmAnd treat a normal map as a roads-only map. I mean that the map data will not be displayed, only roads from the routing data blob as map data.

And when you are cycling or walking (in nature or in a city), you "switch" the checkbox to show all that map data.

And maybe some intermediate form would be possible as well. Actually the current roads-only maps are in that intermediate form. But in that case you need roads-only maps for driving and another full map for cycling/hiking which also forces you to activate/deactivate the several maps before one of those activities.

And to Stefan: I guess nobody outside the dev team has the knowledge to use these tools. Next to that: OsmAnd is a mixed bunch of Java and C++. I think that complicates it a lot as well.

Harry

[Harry van der Wolf]

2016-03-31 9:59 GMT+02:00 Harry van der Wolf <hvd...@gmail.com>:

Warning: long mail ahead :)

Part of the problem is the huge amount of map data.

If you compare OsmAnd to other nav apps, you see that the amount of map data and details is the highest of all (and so is the size).

Here Maps, Mapfactor Navigator, Navmii, Google Maps: not one of them contains that much detail. Google Maps as such does but not when in navigation mode.

Maybe the OsmAnd code is relatively well optimized already but if you need to display/render such an extreme amount of extra data you will never be able to do that fluently unless it is on a high-end phone and maybe when using multiple processors.

I have multiple times asked for a render mode that was as clean as possible for car navigation because all this unnecessary data only distracts your from what is really important. That is also exactly what the other nav apps do: They show you what you need to see while driving. All those "stupid" details are unnecessary. (Whereas you want to see those details while cycling or hiking).

The roads-only roads do exactly this and they are much faster. If you compare these roads-only maps with e.g. Mapfactor Navigator and Navmii, these contain less data, but it's not a big difference as these maps are quite "empty" as well.

I forgot something when re-editing: "If you compare these roads-only maps with e.g. Mapfactor Navigator and Navmii, these roads-only maps contain less data, but it's not a big difference as the Navigator and Navmii maps are quite "empty" as well.

[Hugo Barrocas]

I have to admit that I do look for POI while driving, check if they are already added, correctly placed, etc. But too much map detail when driving (and single core ability) does slow it down.

That idea of checkboxes for not-so-detailed map driving mode could be nice, and you're right, It could be one less map (roads-only) to care for, without the fuas of activate/de-activate maps, but that smaller road-only map can be nicer to download for someone with limited data access.

I believe they already tried doing something close to that, in automatic form, when Osmand would change the current profile acording to gps speed, but at the time it didn't quite workout because it was only guessing and messed what the user expected.

For example, you are in walking profile, and the speed goes to 80km/h, then it could change to car mode (unless you are a beep-beep runner! ).

Some map data (like paths) already does not show in car driving mode.

--
Cumprimentos,
D.er Hugo Barrocas

[Andrew Davie]

I am very new to OsmAnd, but since I am contributing code in the GPX rendering area at the moment - as well as improving functionality I am very interested in performance issues. Now i know my code isn’t perfect, but it’s not bad either - and being from a graphics/gaming background I’m very interested in performance in that area. I have tried to make my code as elegant and efficient as possible. As I learn more about OsmAnd I will be interested in improving performance and contribute/suggest where i can. It would be useful to have some guidelines pointing towards just what you think is bad, and how much better it could/should be. The point being, if people are going to spend time optimising then it should best be done in… the optimal places. I don’t speak for the developers but I would be surprised if bounties would work; my motivations at least are those other than money.

I have built my own maps; the process involves sub-sampling many tens of thousands if not hundreds of thousands of images. That is in my opinion one of the major reasons why it takes a long time :)

[Poutnik]

I had perhaps naive end user understanding
that amount of rendered data
and in consequence the rendering speed
is/can be determined by rendering styles.

But I guess it is more complicated.

--
Poutnik

My Brouter profiles
https://github.com/poutnikl/Brouter-profiles/wiki

[Harry van der Wolf]

@Poutnik: about a year ago I have been trying to work on this as well.

OsmAnd simply reads all data for the given area and zoom factor, and then decides by some "if-then-else" rules (I think) based on the rendering style what to display and what not. This second step is not very efficient.

The rendering style determines renderings speed by 10-20%. And that's a a very rough estimate. I tried all kind of rendering options and "leaf out objects" but it didn't make a big difference and was very hard to exactly measure.

simply switching from full maps to roads-only maps is easily to measure and very consistent.

[Hugo Barrocas]

Re-thinking about this...

There's already some checkboxes for 'Configure map - Detail', like 'more details', 'OSM assistant'.

I have these checked all the time for better view of the map details, to see what need to be worked on the map. But when driving, most details are not needed, as stated.

What I think could help out, was a way to make the 'more detail' option behave in a similar way to having activated the road-only map, and change to that mode, according to what we are doing.

So, if I'm at walking speed or stopped, Osmand has more time available and could render in full detail, but when speed goes up, most non-road details could be omited to gain rendering speed (and avoid driver distraction).

Stopping at traffic lights or at the road side, full rendering again.

But would this mean the comeback to auto-profile changing again?

[Poutnik]

IT could have sense for visual comfort...

But what I understand from Harry,
the speed gain for minimal rendering would be small
in current implementation read-all-decide-if-to-display.

Dne 31/03/2016 v 10:44 Hugo Barrocas napsal(a):

Poutnik ( The Wanderer )

[Andrew Davie]

One of the debugging tools available to developers is an “overdraw” indicator. This colours the screen elements according to how many times they are redrawn (or more specifically pixels are individually coloured redder when they’re drawn more than others, which are bluer.  Here’s a snapshot of OsmAnd which, much to my surprise, indicates a lot of overdraw going on in those buttons/controls… and not much on the screen itself…   

[Hugo Barrocas]

Playing around with it just now, I can see the difference it makes from the having the 'full map' to the 'road-only map' when driving, or even just panning the map, but you're correct, if the data is all there and Osmand has to read full map anyway, and then decide what to show, may not be the best way.

[Hugo Barrocas]

I have a phone that can play full 3d games at full speed smoothly without a glitch, and yet it struggles to render Osmand in 2d.

If Osmand only uses single core processing, making it use the full multi-core potencial would make a huge difference, and be the best way to go, but I guess that may be easier to say than to do (or else it would already be done)?

[JeCh]

I would like to mention Sygic (or it's free clone Be-On-Road) as the most smooth and fluent navigation. It shows a lot of details too. For example iGo has a lot of details and is still much faster then OsmAnd.

I see two root cases of the problem:

1) Osmand is not multi-threaded
2) Osmand doesn't use OpenGL

Every modern phone has at leas 4 cores, some have 8 some will have even 10. If Osmand uses just one of them, it gets only a small portion of the phone's power. Imagine how nice it would be to increase the rendering speed 4x.

But that's not all. Remember 1.x versions of Mapfactor? They were not using HW rendering (just like Osmand). Even with the very few details in map the movement was choppy. Now Mapfactor 2.x shows 3D semi-transparent buildings and is perfectly fluent. Why? They introduced OpenGL rendering.

Both tasks are very complicated and need a lot of work. But Osmand can not compete with other navigation apps without them. Modern phones don't add much per-core performance. They increase number of cores and graphic card performance.

[Harry van der Wolf]

2016-03-31 17:00 GMT+02:00 JeCh <vladimi...@gmail.com>:

I see two root cases of the problem:

1) Osmand is not multi-threaded

Correct. 

2) Osmand doesn't use OpenGL

Not entirely correct. But the OpenGL rendering mode is hidden and maybe still experimental (be it then for at least 1½ year)

Go to Settings ->Plugin Manager and select the "OsmAnd Development" plugin (the bottom one) and enable it (of course).

And then enable the "Use OpenGL rendering".

For me the setting makes absolutely no difference. I have the idea that its even slightly slower. (on Samsung S5 mini stock android 4.4.2)

But that's not all. Remember 1.x versions of Mapfactor? They were not using HW rendering (just like Osmand). Even with the very few details in map the movement was choppy. Now Mapfactor 2.x shows 3D semi-transparent buildings and is perfectly fluent. Why? They introduced OpenGL rendering.

Yes. I remember (I am one of the test users since I stopped using OsmAnd for car navigation*) but you are not correct in your assumption about the behavior of the 1.x versions. The way they build up the map in the 1.x versions is completely different to what OsmAnd does. The have an update frequency of a couple of frames per second (5? 10? 15?) . Per refresh they simply put a full "screen map" onto the screen. That looks indeed a bit choppy. But Mapfactor never(!) missed parts of the screen like OsmAnd does because OsmAnd indeed does not perform enough.

That part I fully agree :)

Mapfactor Navigator is fluent with their new OpenGL mode because they use a "prediction algorithm". This same algorithm, giving a smooth motion, sometimes fails thereby projecting your position next to the road because the curve is incorrectly "predicted". They still need to work on that.

*: No I'm not a traitor. I want the best for everyone and that includes of course myself. I do my best to put everyone forward. As OsmAnd moved way too slow, focusing on other "enhancements" instead of screen performance and route calculation and already for the past 1½ years, I did move forward. But OsmAnd, completely open source, is still a very interesting project.

Harry

[Jan van Bekkum]

Something else must have happened as well: I am now Back to 2.1, a real improvement over 2.3. Version 2.2 was already slower and crashed a lot more than 2.1. I had hoped 2.3 would be more stable, but crashes as least as often as 2.2 and is a lot slower. The 2.3 user interface may be a bit more polished, but overall 2.1 works the best for me. As the amount of data displayed is the same for all versions something else must be going on.