my earlier problem with backup/restore is now solved. backup to and restoring from google drive works :) backup and restoring locally works too :)
I also have found a solution for my problem with updating the beta app in google play store. This problem occurred on the genymotion virtual machine on my pc. I now use the cyanogenmod 13 version of android-x86 in virtualbox. Mapfactor beta runs ok in this emulator and is automatical updated.
Is it possible to include the file "navigation.xml" in the backup???
I have my "navigation.xml" file modified so that it does not announce the waypoinst anymore. With every update this file is reset to the original version. It would be nice if I could backup this file also.
Renderer - Automatic => 2D mode => auto zoom => no - Software => 2D mode => auto zoom => yes, but bad quality - Hardware => 2D mode => auto zoom => no
- Automatic => 3D mode => auto zoom => yes => road border width => problem - Software => 3D mode => auto zoom => yes, but bad quality => road border width => Ok, but small - Hardware => 3D mode => auto zoom => yes => road border width => problem
We added into renderer dialog "Software low resolution" and changed order of items but as our crowdin account is suspended, it used old texts and old text positions so thats why our last build is broken.
What is "zoom" for you? (map resolution, autozoom, zoom buttons, pinch to zoom, ...)
@lubos, version 3.1.95 (no eink mode to test) autozoom in navigation mode : Renderer Automatique : - 2D = not zoomed enough - 3D = ok Renderer Hardware : - 2D = not zoomed enough - 3D = ok Renderer Software : - 2D = really too small - 3D = not zoomed enough Renderer Software Low resolution : - 2D = ok - 3D = ok
Automatic renderer is not needed to report (it just switch between hw/sw renderer according to device parameters). Version 3.1.x is closed for bigger modifications which is this case. So I will work on it in the next major update (as like as eink lines support).
Some remarks on working in navigation mode (3D) using different rendering (ver 3.1.95). MFN chooses automatically for my phone hires software mode (LG K10). This mode looks very nice (much better than lores) but there are some missed functionalities in compare to lores mode. First of all size of fonts (village names, streets), POI and HD Traffic icons is far to small (and doesn't change after changing settings with proper sliders). Zooming out is great, showing large map area but zooming in (for instance on roundabouts) is not enough. And there is lack of road numbers showed on a map after zooming out (which are present in lores mode). Similar situation is observed in hardware mode but in that mode size of fonts is at least big enough (icons - especially HD Traffic icons - are even smaller). And in hardware mode other functions of my phone are almost dead (not enough resources). So for now I'm staying with lores mode - although hires seems to me to be great choice for low end phones after fixing/implementing mentioned issues.
I've observed strange behaviour of MFN - is it possible that rendering mode influences on route calculation? Today I've changed rendering mode to hi res software mode and route calculation was little bit strange directing me into the traffic. After changing to low res route was calculated properly. The same situation i've observed yesterday. Hardware mode gives the same result as low res software mode (good one)
The second thing is that in low res software rendering mode there is substantial lag between actual position and position showed on the map during navigation after longer trip - let's say more than 50 km. It's especially annoying on crossroads or roundabouts when i'm already after manoeuvre and navigation shows that i'm still before. This lag is also present just after beginning of the trip but on short distances is not so annoying (position is showed just behind me - let say not more than 10 m). GPS receiver in my phone works rather correctly - in hardware rendering mode position is showed very accurately.
2. Hmm... But in hardware rendering mode position is showed properly (I agree that my phone is not powerful enough for hardware mode, but it's rather problem of using other functions of phone during navigation - MFN works ok in HW mode)! I'm observing this lag in low res software mode...
Let me correct Tomas's answers: 1) When you use HD traffic it can happen that route will not be the same (with different renderers). The second thing is that in navigation mode the route starts from GPS position (it can happen that precision of this position is very bad - e.g. 1km away and then the route can be different). 2) Software renderer redraws map together with GPS position update rate (once per second) + there is slower rendering (you see map 100-1000ms later) so it is always slightly behind. Hardware renderer extrapolates GPS position so it is more actual.
1) - It's probably the effect of HD traffic - later I was experimenting with route calculation function (in map mode) after choosing start and destination points and results of route calculations were different depending on rendering mode (traffic info was the same).
2) The problem is, that in the beginning of the navigation (and let's say for the first 30-50 km of the trip) MFN behaves as You've described. But afterwards it seems that MFN somehow starts to show not "current" GPS position but rather "previous", and the lag between real current position and position showed starts to be substantial. Maybe it is because of this wide range ot time needed for rendering the map (100-1000 ms) - at the beginning of the trip it is closer to 100 ms, but during the trip it elongates (don't know why - maybe because of the way how Android is managing the tasks) up to 1000 ms which gives the same effect as to show "one step back". This situation can be corrected only by restarting MFN (restarting navigation doesn't help).
OK. So for now i'll stay with HW rendering, because in that mode MFN shows position very accurately :) (of course when there is enough amount of GPS satellites visible).
The 100-1000ms rendering time is for software renderer only. Hardware renderer renders map in about 30ms. What you describe is a known issue that Navigator during usage become slower (we know it is happening but we does not know why - I guess it is some thread issue that threads which finished the task are still active). The most devices start having the problem after about 300km.
So it seems, that slowing down problem is much more visible in SW render mode. During my vacations in summer, i've used MFN on PL-HR, HR-D and D-PL routes (over 1000 km each) in HW render mode and i haven't observed this issue (maybe apart of slowing down overall performance of my phone during navigation ;) ). Nowadays i'm testing SW render mode and i've started to observe described problem.
Yes, i've started to observe too. My Lenovo P780 during usage MF 3.1.95 become slower. This began to happen after I paid for the premium features.:( This occurs within a few minutes of the program's launch, maybe 3 or 10min. According to my observations routing calculation (as well as other program features) doesn't affect this. I can do nothing (just launch the programm is neded) and it still happens. Only relaunch helps me. I use HW render mode, HD traffic turned off.
Perhaps a small hint from a newbie as it might help.
On my S5 I have the device's developer options enabled. There are several options for rendering, for example force GPU rendering only or deactivate hardware overlays. I have both tagged and cannot complain, MFNapp is running in hardware mode.
Sometimes I'm navigating more than 500 km a day and when not navigating I use gpx recording a whole day long. I never had to complain about MFN slowing down, also stability is veeeery close to perfect.
Bytheway, SW render mode is litle bit slow on my phone. HW render mode, more often works pretty well but sometimes it works like SW mode. Automatic tag always turns on SW mode.?
Dear developers, if you really want to understand the reasons, pay attention to the implementation of OpenGL.
The text size in My Places and Routeinfo is to big. How to setup a smaller size? I use a Samsung Galaxy Xcover3. This have not a Full HD Display, maybe don't use pixel size use display size.
just out of curiosity - why do you have so much geometry for rendering? Is it really needed?
This issue has actually made me switch to a different application because my - let's say midrange - phone (Huawei P10 Lite) has become useless when trying to zoom into an area with more items (e.g. bigger city).
Other applications that use OSM data render their maps at least 10 times faster...
I'd suggest to make this a high priority point for the next release
We are using vector maps, if you are in detail it renders N geometry. If you zoom out 1x, it renders 4xN geometry, if you zoom out 2x then it renders 16xN geometry...
We would have to add into 2x unzoomed map decimated geometry, which would make mca files bigger because there would be more geometry inside.
We have no capacity to solve it. You can switch to HW renderer where the most of devices do not have problem with it.
Maybe creating a Lower Resolution HW renedring profile (just like you did with the SW rendering) would help - for example render HD resolution on a FHD display...just a thought
I also noticed that when I turn off debug then it's a lot better
I've changed my phone to LG G6 (much more powerful than previous LG K10) and everything works perfectly except zooming :(. Automatic zooming in navigation mode (HW renderer) doesn't work at all. Navigation starts with high level of zoom (as used for crossroads and this doesn't depend on zoom level previously used). When I zoom out (by button (-) or gesture), after few seconds MFN zoom in to the level in which buildings are rendered in 3D and stays with this level until exit from navigation mode or recalculation of the trip. Then it returns to the beginning state (high level of zoom). On LG K10 automatic zooming was working OK - zooming in on crossroads with planned manoeuvres, zooming out "in between" and with fast zooming change to indicate closing manoeuvre (great feature by the way).
MFN ver. 3.1.105
Edit1:
SW renderer does autozoom properly, but only in lowres mode. In hires zoom level is also constant, but it seems to be rather zoomed out
Edit2:
After my few journeys I've got some remarks on HDTraffic. Lately I've driven couple of times from Kraków to Tatra mountains on route 7 which is very crowded in season and traffic situation can change rapidly. I've observed that MFN can't "go back" to previously calculated route when jam is not present any more. In details: When MFN gets info about traffic then it recalculates the route to avoid traffic jams - as it should be. But then MFN "forgets" about previous, initially the fastest route and monitors only the new one. When traffic situation is cured on the fastest route MFN doesn't go back to this route but continuously avoids traffic jams which are not existing any more - one needs to restart navigation to go back to the fastest trip. This behaviour is probably ok when change in the trip is "just behind the corner" and new trip is immediately different from the old one. But i've got situation when i should leave the old route after 50 km, and during the time needed to reach this point traffic situation on old route has cleared - so it would be nice if MFN monitor the orginal route and recalculated one up to the point from which they are different to react properly on new HDTraffic info.
End the second thing is - are there plans to have HDTraffic in MFN for other European countries i.e. SK, H, HR? On TomTom web planner for SK and H such info exists...