Slow Rendering on Pixel 8 Pro (stock OS)

xxyxxyxyx1 commented 7 months ago

Description

Browsing offline maps is very slow with OsmAnd. When I scroll to the side, I need to wait about 1 seconds for the map to re-render. This makes the experience unpleasant, and very impractical when browsing along a planned route or looking for something. The device also gets noticeably hot and loses battery quickly.

I am using a Google Pixel 8 Pro, a fairly recent and powerful phone. I do not have rendering delays or feel a hot device with any other applications. For example, with komoot maps, organic maps, or google maps, I can scroll the map nicely without delay.

I think there is probably some bug or incompatibility with my particular device, I doubt others would actually be using an app like this. Unfortunately there are no app crashes or visible errors to report.

I have tried using the default "version 2" renderer, and the "version 1" renderer; the "version 1" is worse. I have not modified any other settings in the OsmAnd app. I have restarted the phone and closed all other apps.

Steps to reproduce

Browse the map

Actual result

Wait a while to browse the map

Expected result

Browse the map without waiting

Your Environment (required)

WARNING Crash-Logs MAY contain information you deem sensitive. Review this CAREFULLY before posting your issue!

OsmAnd Version: 4.6.13 from Play store
Android/iOS version: Android 14, stock OS for the phone, dark mode
Device model: Google Pixel 8 Pro
Crash-Logs: ?

Zero3 commented 7 months ago

Same issue for me after updating to OsmAnd 4.7.9 on a Google Pixel 7a. Used to work fine, bit map rendering now takes many seconds every time it is redrawn, making the app almost unusable. After a while it even crashes.

sonora commented 7 months ago

Possibly connected to https://github.com/osmandapp/OsmAnd/issues/19373, I had already noticed in our nightly builds some weeks ago.

DmitryAlexei commented 7 months ago

@xxyxxyxyx1 @Zero3 Could you please provide more information about locations and zoom levels where slow rendering can be observed? If it is possible, please provide short videos of your issues and your profile settings (go to menu > settings > profile > export profile) Could you also update your apps to the latest versions and cheek if the issue persists?

Zero3 commented 7 months ago

@DmitryAlexei I noticed the issue in the city of Odense, Denmark. I did not test other places. Zoom levels were whatever turn-by-turn navigation used, which depends on speed etc, but quite zoomed in overall. I believe the issue was present if I manually zoomed out as well.

I was already running the latest version from Google Play. But I signed up for the Google Play beta program and temporarily upgraded to beta version 4.7.10 which seemingly has fixed the issue for me.

xxyxxyxyx1 commented 7 months ago

I am now on version 4.7.10 and the issue is not improved.

I can reproduce it by opening the app fresh and:

switching to the default pedestrian (walking human symbol) map style
typing "Berlin" into the search, tap "show berlin on the map"
swipe around with one finger, not changing the zoom

It takes >1 second to render the view each time I scroll, about half of the time to resolve the big grey squares and half to fill in the details. In other maps apps, at approximately the same location and zoom and scroll, there is no perceivable rendering lag.

I've just installed the app "Wattz", and it shows 5-10 watts of consumption in my top bar while scrolling, which I believe indicates the app is able to access plenty of computational resources.

APneunzehn74 commented 7 months ago

Can confirm the problem with slow map loading after zooming and swiping. Problem occurs as soon as live updates are activated. Gigaset GS5 and GX4 OsmAnd Version 4.7.10

cricri-du-lauragais commented 7 months ago

i've noticed this problem recently with my + version of the playstore on my galaxy a33 android 14 phone and on windows 11 with the nightly version, it's especially obvious when i zoom out or swipe, i see squares drawn one by one all over the newly displayed surface. when I test the same way with the latest f-droid version, it's much faster.

xxyxxyxyx1 commented 7 months ago

I installed the current version from fdroid called "OsmAnd~" v4.6.14. @cricri-du-lauragais, is this the version you are using?

For me, the rendering is not any better than the google play version.

cricri-du-lauragais commented 7 months ago

I installed the current version from fdroid called "OsmAnd~" v4.6.14. @cricri-du-lauragais, is this the version you are using?

For me, the rendering is not any better than the google play version.

yes without 3d

Uinsart commented 7 months ago

Same here with my Pixel 6. Can confirm that my wife's Pixel 6 with the exact same configuration, but no hourly updates works fine. Mine renders very slow.

I uploaded a screencap.

https://github.com/osmandapp/OsmAnd/assets/65364200/2353c42e-e555-45a8-af5e-de767b11ebc7

MarkusGaugg commented 7 months ago

On my phone since the 4.7 update unusably slow, the map only loads after 5 seconds and after zooming it takes as long again until the map is displayed. The app crashes after a minute at the latest.

MarkusGaugg commented 7 months ago

Device : r9q Brand : samsung Manufacturer : samsung Model : SM-G990B Product : r9qxeea Build : UP1A.231005.007.G990BXXS7FXD2 Version : 14 App Version : OsmAnd+ Apk Version : 4.7.10 4710

logcat.txt

DmitryAlexei commented 6 months ago

@MarkusGaugg could you please try the latest version from Google play and tell if it is working better?

APneunzehn74 commented 6 months ago

For me the problem disappeared over the weekend after the map update. I suspect the Bavaria map was the problem. Current version 4.7.15 Beta.

Uinsart commented 6 months ago

Can confirm with the newest (Beta)Release from Google Play the problem is gone. Thanks!

MarkusGaugg commented 6 months ago

@DmitryAlexei Thank you for this update. The update alone didn't completely fix it, but since I installed the latest May maps, in conjunction with today's update, it's running like before. Like the user @APneunzehn74 I also use the Bavaria map.

Uinsart commented 6 months ago

Same here, Bavaria

xxyxxyxyx1 commented 6 months ago

@vshcherb , my original issue has not been resolved. I don't think this should be closed. This issue turned into a discussion about an unrelated problem with Bavaria map. I do not use the Bavaria map, and my performance is still bad on 4.7.15. I would be happy to provide further information if it would be helpful.

breversa commented 6 months ago

Same here on my Samsung Galaxy S9 using the current F-Droid version (net.osmand.plus 4.6.14).

(I'll add more details when I'm back at my desk).

Also, energy consumption feels very high especially when using routing. See attached during a 3-km bicycle route simulation.

Additional info:

Device: Samsung Galaxy S9 SM-G960F
OS: /e/OS 1.21r
Android: 11
OsmAnd: net.osmand.plus 4.6.14 from F-Droid

runejuhl commented 6 months ago

FYI I'm seeing the same issue with F-Droid version 4.7.10. I'm not completely sure when the issue started occurring, but it might have been after an upgrade from Android 13 to 14.

I've tried deleting cache, disabling live updates (which seemed to help, but only for a short time) and disabling recorded tracks, but the issue persists.

runejuhl commented 6 months ago

Just tried deleting cached data again and then downloading the most recent map of Denmark, and lo and behold, OsmAnd is now rendering at (or about at) it's usual speed and OsmAnd no longer crashes.

xxyxxyxyx1 commented 6 months ago

Same here on my Samsung Galaxy S9 using the current F-Droid version (net.osmand.plus 4.6.14).

I also experience similar battery drain, up to 1% per minute of screen-on usage.

Did you ever experience better performance than this with OsmAnd, perhaps using a different device or software version?

This was my first time using OsmAnd; I was excited for the features, but performance and battery are so much worse than other apps. But I don't actually know if I'm experiencing a bug, or if the app is just like this for whatever reason...

sonora commented 6 months ago

1% per minute is definitely not normal. In my experiences using OsmAnd is roughly comparable to surfing the web, i.e. power consumption is mainly governed by the screen being on (if just viewing the map), and if in addition you use navigation some background CPU usage. Depending on your device, even in the latter case you should easily get like 5+ hours...

breversa commented 6 months ago

Did you ever experience better performance than this with OsmAnd, perhaps using a different device or software version?

OsmAnd has never been easy on battery nor very high on performance (to be honest), but I believe that things were better just after OpenGL 2 versions came out. I've switched to Magic Earth for car travel because of the much better performance (and since it's included in /e/OS).

Also, I confirm the 1%-per-minute battery drained, on a fresh install, with only 1 or 2 local maps, no routing, just displaying the map while driving. It also crashed at least 3 times in 15 minutes. My music app kept getting killed as well (see https://github.com/osmandapp/OsmAnd/issues/16578).

If I scroll the map manually, and especially zoom out, OsmAnd will take several seconds to display the new zone and its details, drawing empty squares first, then an increasing level of detail.

I feel that something is wrong with the way OsmAnd displays the map, as if it was using very inefficient algorithms that put a lot of stress on the CPU (singular or plural?).

(I have a spare Wileyfox Swift 2 at hand and will do some more testing with it.)

breversa commented 6 months ago

On the Wileyfox Swift 2 running LineageOS 18.1 (Android 11) and net.osmand.plus 4.6.14 from F-Droid, the battery lost 25% in 95 minutes, so about 4× less than on the Galaxy S9.

However, the phone was static so no new map subsection to load.

I'll give it another try with a simulated routing.

breversa commented 6 months ago

So, I did the following test with the Wileyfox Swift 2:

Phone has no SIM card nor wifi
Downloaded only one local map
Charged the phone to 100% (2700 mAh battery, but I don’t know its age/degradation)
Simulated one bicycle route (to force the app to draw new elements)
Kept the screen on

Result: The simulated route took about 105 minutes and ate 70% of the battery, which is roughly in line with the observed 1%-per-minute (0,6667%/minute). The phone went progressively warm/hot.

This seems to show that it’s the drawing of elements that uses an abnormal amount of power.

I’ll give it another try but with a simulated car route, to generate faster redrawing.

EDIT following https://github.com/osmandapp/OsmAnd/issues/19511#issuecomment-2114425306: 0,6667%/min = 16,187476 mAh/min

breversa commented 6 months ago

Here's another test (using Battery Guru) with a simulated car routing:

Not as bad as I had expected, but still around 0,5%/minute of use.

EDIT following https://github.com/osmandapp/OsmAnd/issues/19511#issuecomment-2114425306: 0,45625%/min = 11,07775 mAh/min

breversa commented 6 months ago

Additional info: Using Battery Guru, I calculated the following:

My Samsung Galaxy S9 3000 mAh battery is worn down to 60% = 1800 mAh, so 1% = 18 mAh
My Wileyfox Swift 2 Plus 2700 mAh battery is still up to 90% = 2428 mAh, so 1% = 24,28 mAh

sonora commented 6 months ago

For comparison:

What are the stats when you just leave the devices statically on OsmAnd's map screen, i.e. with no navigation or similar OsmAnd task ongoing?
What are the stats when you just leave the devices statically on another app's screen (i.e. test the consumption of your screen, this is a major consumer on most devices, and it strongly depends on the brightness set etc.)

breversa commented 6 months ago

Static device on OsmAnd = 7,1328 mAh/minute

breversa commented 6 months ago

(I realized that I'll be clubbed by any mathematically-skilled (or physics) person for typing "mAh/minute" ^^')

sonora commented 6 months ago

So now it would be interesting to see how that device behaves with another app under similarly static conditions, i.e. with the screen on. I suspect what you see here may primarily be the display using the power, nothing OsmAnd specific, but that exactly remains to be verified or falsified.

breversa commented 6 months ago

Here you are.

Translation: "Durée totale" = total duration "Utilisé" = used "Taux de décharge" = discharge rate

"Temps d’écran allumé" = screen-on time

"Temps arrêt de l’écran" (bad translation) = screen-off time

So from what I can tell, the device discharges about:

3%/h with the screen on
15%/h with OsmAnd simply displaying the map
30%/h when actively routing!!

(This conversation has deviated from the original issue being slow rendering. Shall I open a new issue?)

breversa commented 6 months ago

Also, I’ve updated OsmAnd~ to 4.7.17 from F-Droid and the map rendering is quite faster, though empty squares are still visible shortly when zooming/panning the map.

sonora commented 6 months ago

Right, that's a great test, thank you! So what bugs me foremost is

3%/h with the screen on 15%/h with OsmAnd simply displaying the map

which seems to indicate OsmAnd is busy doing something very obsolete while simply statically displaying the map. I guess the dev/investigation team should now focus to find what that could be.

Yes, caching was fixed/improved in v4.7.17. Does using 4.7.17 alter your above findings about OsmAnd power consumption?

breversa commented 6 months ago

Yes, caching was fixed/improved in v4.7.17. Does using 4.7.17 alter your above findings about OsmAnd power consumption?

I will start another batch of tests (screen on, OsmAnd idle, OsmAnd routing) and open a new issue in order to get as many facts straight. :-)

derkrasseleo commented 2 months ago

I also noticed on my Pixel 4a that rendering after zooming vor scrolling is taking for ever vor not even loading at all if I don't touch the screen a second time. Offline map, live updates are off, all other map features off (no contours/relief etc.). I downloaded OsmAnd 4.8.5 from F-Droid

osmandapp / OsmAnd