navit-gps / navit

The open source (GPL v2) turn-by-turn navigation software for many OS
http://www.navit-project.org
Other
558 stars 175 forks source link

Mio P550 WinCE #1053

Open hviagov opened 4 years ago

hviagov commented 4 years ago

Navit running slow on WinCE

Hi guys! I want to check your app and get it for my old Mio P550 WinCE device. Figured out that it is running very slow and the refresh rate also very slow. The version i grab is 0.5.5 for WinCE and as attachment i send you my configuration and the debug log i enabled after experienced that behavior. navit.log navit.xml.txt

Have i missed something?

cheers, hristo

lains commented 4 years ago

Hello,

The last build from sources I did on my Mio C210 is one year old, and was already abit slower than 0.5.3 Maybe transparency and other map drawing features are slowing the rendering, maybe also the traffic code could slow down things, but I am 100% sure. If there are compile-time options to disable these features, maybe this is a first attempt that can be made. I guess you used a pre-compiled binary version, right? Did you unlock your P550? If anything is different from the Wiki, it would be a great thing if you could document the procedure for others.

Thanks

metalstrolch commented 4 years ago

Before trying to recompile Navit, or to point to transparency (does WinCE even support?), I want to remember #953 and it's outcome. #906 already tried to do something about that issue, but only for the "really large".

Where did you get the maps from you are using? From planet extractor? If extracting an area from an existing binfile (which planet extractor does) you need to keep all tiles which intersect the area you want to have up to the largest one spanning all over the world. On processing the world map nowadays a lot of large polygons get shifted into the higher tiles. So the higher tiles get quite big nowadays. The introduction of multipolygons gave this a boost, but only because we have now things in map that were long time missing. Now every time you want to read any element out of the binfile map, one needs to extract the bigger tiles as well. This requires a lot of memory, as one needs to be able to cache those bigger tiles in order to be fast.

When processing a custom map using only extracted OSM data for that area, you do not have much in the higher tiles as you may not have e.g. elements crossing the equator if you OSM excerpt does not cross the equator. -> Pick the area of map you want to have e.g. from Geofabrik and then run maptool on your own. Now as an extra, compare the size of this binfile with the size of the same area from planet extractor, and you get the problem.

Yes, as a conclusion map gets too big nowadays for constrained devices. There are single polygons bigger than 20MiB in the map nowadays (Lake Nasser, Egypt).

metalstrolch commented 4 years ago

I can offer to process a custom map to try out if it is not to be too big.

mvglasow commented 4 years ago

maybe also the traffic code could slow down things

Off the top of my head, traffic should have hardly any performance impact when using the null plugin (which is the default for all platforms except Android), or when no messages are being reported—the most costly thing about traffic is processing traffic messages.

hviagov commented 4 years ago

Before trying to recompile Navit, or to point to transparency (does WinCE even support?), I want to remember #953 and it's outcome. #906 already tried to do something about that issue, but only for the "really large".

Where did you get the maps from you are using? From planet extractor? If extracting an area from an existing binfile (which planet extractor does) you need to keep all tiles which intersect the area you want to have up to the largest one spanning all over the world. On processing the world map nowadays a lot of large polygons get shifted into the higher tiles. So the higher tiles get quite big nowadays. The introduction of multipolygons gave this a boost, but only because we have now things in map that were long time missing. Now every time you want to read any element out of the binfile map, one needs to extract the bigger tiles as well. This requires a lot of memory, as one needs to be able to cache those bigger tiles in order to be fast.

When processing a custom map using only extracted OSM data for that area, you do not have much in the higher tiles as you may not have e.g. elements crossing the equator if you OSM excerpt does not cross the equator. -> Pick the area of map you want to have e.g. from Geofabrik and then run maptool on your own. Now as an extra, compare the size of this binfile with the size of the same area from planet extractor, and you get the problem.

Yes, as a conclusion map gets too big nowadays for constrained devices. There are single polygons bigger than 20MiB in the map nowadays (Lake Nasser, Egypt).

i got the map of Austria from geofabrik.de and convert it into binary using maptool. Interesting is that the same map has been used with my navit on raspberry pi (self compiled) and works like charm

hviagov commented 4 years ago

I can offer to process a custom map to try out if it is not to be too big.

yes, let do it if you have some that i can try

hviagov commented 4 years ago

if it does not work i will just use it with raspi, it's much more reliable that the winCe

metalstrolch commented 4 years ago

OK, I rolled you a map of austria using current trunk maptool using geofabrik austria excerpt. It can be downloaded there : http://metalstrolche.de/austria.bin

However since you did essentially the same, I fear we're hunting something else causing the winCE device to be slow. Do you know the amount of ram the Mio P550 device has? Usually performance problems were tied to the ram size, as those wince devices seem to be very low end, even for production time standards.

hviagov commented 4 years ago

OK, I rolled you a map of austria using current trunk maptool using geofabrik austria excerpt. It can be downloaded there : http://metalstrolche.de/austria.bin

However since you did essentially the same, I fear we're hunting something else causing the winCE device to be slow. Do you know the amount of ram the Mio P550 device has? Usually performance problems were tied to the ram size, as those wince devices seem to be very low end, even for production time standards.

Unfortunately i can't download the file, some how the request is not completing. Can you check the link plz.

metalstrolch commented 4 years ago

Have you been able to get the map? It's ~430 MB.

hviagov commented 4 years ago

Hi and sorry for my late answer, i found more time and trying the map right now and i can write some few rows later. I see that ui is actually written in html and asked myself if it is possible to implement it in angular or reactjs. What do you think about that?

hviagov commented 4 years ago

Hi Strolch! That map is working. Why is the map working :) don't get it. Can you explain me?

hviagov commented 4 years ago

so i have restared navit 2 times and i have the yellow screen again

metalstrolch commented 4 years ago

Having only the yellow screen might just indicate your navit is centerd into a not mapped area. Remember: the map provided by me just contains Austria. Got to town search and try to find any town in Austria. Then locate on map.

My map build is working, because I processed only an OSM data excerpt. So the map does not contain any data in the highest tile layers, as there was no data present in my input to maptool. When you extract Austria from e.g. world binfile, then the extractor needs to keep all higher level tiles that somehow intersect with Austria. That's what the planet extractor is doing.

But since you said you processed your ma using maptool from a geofabrik OSM excerpt, then my question is: What version of maptool on which platform? Because I virtually did the same. I used .osm.pbf of Austria from Geofabrik to do convert via maptool. My map was processed on x86_64 Linux using maptool from the then trunk head.