osmandapp / OsmAnd

OsmAnd
https://osmand.net
Other
4.72k stars 1.03k forks source link

Slow rendering on Pixel 8 / Graphene OS #18867

Open Redsandro opened 11 months ago

Redsandro commented 11 months ago

Description

When acquiring a replacement for my damaged 2019 smartphone, I made the mistake of assuming that Google's Pixel device would be the most hassle-free device because Android is also a Google product.

It turns out OsmAnd map drawing is very slow on this 2023 device. OpenGL rendering is slower than render engine version 1.

This issue doesn't seem to be tracked yet so I thought I'd open one.

Steps to reproduce

Run OsmAnd render engine 2 (OpenGL) on a Pixel 8 device and compare with 5 year older device.

Actual result

Notice map drawing speed is considerably slower.

Expected result

Map drawing speed equal or faster.

Your Environment (required)

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

OsmAnd Version: 4.5.10
Android/iOS version: GrapheneOS Android 14
Device model: Google Pixel 8
vshcherb commented 10 months ago

That's very strange, we have Pixel 6a and it's very fast. Please try release version and share how the rendering looks like.

Redsandro commented 10 months ago

Okay. I just tried tried OsmAnd 4.6.11 released: 2023-12-28, it's the latest I can find. Rendering looks the same as the 4.5 version. It takes over 5 - 10 seconds to draw a screen in a big city.

Redsandro commented 10 months ago

Here is a screen recording using OsmAnd 4.6.11 on a Google Pixel 8.

https://github.com/osmandapp/OsmAnd/assets/1702193/83db78fc-87f6-4518-9ef5-3c8470da9045

Depending on zoom level, render time averages between 2 and 12 seconds.

I know OsmAnd draws a lot of detail, so it's hard to compare. Organic Maps draws screens in the same area mostly under a second.

vshcherb commented 10 months ago

This definitely not normal even for Pixel 6, but for Pixel 8 it's totally unexpected. We need to understand which optimizations are turned off or what's the issue.

yuriiurshuliak commented 10 months ago

Could you confirm if you're using the release version downloaded from the Google Play Store? Additionally, have you tested this on both the stock Android and GrapheneOS?

Redsandro commented 10 months ago

Could you confirm if you're using the release version downloaded from the Google Play Store?

Yes. The recording is made with OsmAnd from on the Google Play store.

have you tested this on both the stock Android and GrapheneOS?

Unfortunately I did not test this on the stock Android, because I don't allow spyware on my phone. It would be great if someone with stock Android on a Pixel 8 can verify this.

I ran 3dmark OpenGL ES 3.1 test and it was smooth as expected, if that helps. Geekbench 6 outperforms stock ROM for Pixel 8 in Single-Core (1634), Multi-Core (4133) and GPU OpenCL (5099). I have no issues with Google Maps, Organic Maps, Flitsmeister or Waze, although those last ones are probably too simple to notice.

key val
Model Google Pixel 8
codename shiba
OS Android 14
ROM GrapheneOS
SoC Tensor G3 (Zuma)
CPU Nonacore ARMv9
Cluster 1 ARM Cortex-A510
Cluster 2 ARM Cortex-A715
Cluster 3 ARM Cortex-X3
GPU Mali-G715
vshcherb commented 10 months ago

We will try to test it further. To do: test on real remote device

vshcherb commented 10 months ago

Get a physical device of Pixel 7 but didn't reproduce it yet, will look for Pixel 8. So might be related to Graphene OS 14 somehow, so I will check for users with it.

https://github.com/osmandapp/OsmAnd/assets/1042025/7b7cce57-a1e0-4da6-8fe6-e5b6b1df5002

sadellie commented 10 months ago

Tested on Pixel 8 with stock ROM. No lag on fresh install from F-Droid.

This is a Graphene OS issue. I have seen multiple issues on different repos where Graphene OS users complain about lags.

Redsandro commented 10 months ago

Thank you for testing, @sadellie.

I have opened an issue on the GrapheneOS issue tracker: https://github.com/GrapheneOS/os-issue-tracker/issues/3150

It may be too quick to dub this a GrapheneOS issue though. It could be, but it doesn't necessarily make logical sense from an empirical point of view. I have nearly 100 apps installed, and OsmAnd is the only app that is lagging, severely. If at least some of the other OpenGL apps were lagging as well, I would not hesitate to blame GrapheneOS.

What does OsmAnd's OpenGL implementation uniquely do that is problematic exclusively on GrapheneOS, exclusively with OsmAnd? How have other map apps, like Maps, Mapy and Organic Maps, mitigated this problem? Can OsmAnd apply the same solution? I don't understand enough about the technical logistics to formulate a proper problem description and hypothesis.

If someone knows specific eccentric OpenGL features that OsmAnd may use and the aforementioned map apps do not, at least I'd have some hypothesis to bring to the table. Otherwise, GrapheneOS will probably close the issue stating it has nothing to do with GrapheneOS.

thestinger commented 10 months ago

@sadellie Please stop spreading misinformation about GrapheneOS.

thestinger commented 10 months ago

@Redsandro If you have an app compatibility issue or an app performance issue, you should try enabling exploit protection compatibility mode. There's also an individual toggle for hardened_malloc to only disable hardened_malloc while leaving other features like extended address space enabled. The default hardened_malloc configuration is heavily security focused and we currently provide a single toggle for using it or not using it rather than offering more detailed configuration. It would be possible to have a whole range of performance vs. security configuration instead of standard Android malloc vs. hardened_malloc but it's simplest to only provide the stock OS option and the default GrapheneOS option. We don't want to make it too complex.

If you've enabled hardware memory tagging for all user installed apps with the toggle in security settings, that's another possibility, but that shouldn't have significant performance overhead in practice. It's possible the app is doing something which causes memory tagging to hurt performance though, but it would be disabled by default for this app unless you enabled the toggle.

sadellie commented 10 months ago

@sadellie Please stop spreading misinformation about GrapheneOS.

There is no misinformation.

Same device, same app, but different OS

thestinger commented 10 months ago

@sadellie

This is a Graphene OS issue.

There's no evidence of it being a bug in the first place.

I have seen multiple issues on different repos where Graphene OS users complain about lags.

Please provide sources.

There is no misinformation.

You're using someone's issue report to maliciously spread misinformation about an open source project.

thestinger commented 10 months ago

https://github.com/organicmaps/organicmaps/pull/7229 is an example of a recent memory corruption bug in a similar app fixed due to being uncovered by a GrapheneOS feature. The first instinct there was to deny it was an issue with the app, but it was a valid bug uncovered by our memory tagging support. Memory tagging is not enabled by default for apps like these due to the potential of compatibility issues from bugs in the apps. There are other features enabled by default with a per-app toggle to disable them that are similar. It's not a bug in the OS for these features to uncover issues in apps. There's an exploit protection compatibility mode toggle for a reason and it's the first and usually only thing people need to try if they run into any app compatibility issue. In almost all cases, it's an app bug, and often worth reporting if it's a crash.

thestinger commented 10 months ago

@Redsandro It's highly likely exploit protection compatibility mode will work around it, and I think it's unlikely there will be any changes due to it not uncovering a crash. It would be possible to fix in the app, but it's probably not actually a bug.

Redsandro commented 10 months ago

@thestinger Wow, this is a big difference! I had no idea, not in the slightest, that this could be related. It didn't occur to me to try this toggle for OpenGL performance. This is indeed much, much faster!

Again, I don't understand the technical reasons for this big difference especially since I hardly notice an impact in other OpenGL apps. So I don't know how much OsmAnd can do to perform better, and at what cost. I don't understand the security implications of the compatibility mode either. But I trust OsmAnd so either way I'm happy.

Let's stay composed, I'm sure no malice was intended. :slightly_smiling_face: Thanks for the suggestion!

thestinger commented 10 months ago

@Redsandro There's likely part of the code which could be heavily optimized which plays badly with hardened_malloc in this case, which is rare. For example, hardened_malloc zeroes data on free and the code might be repeatedly allocating/deallocating a large allocating and spending a lot of time zeroing it on free.

thestinger commented 10 months ago

I don't understand the security implications of the compatibility mode either

It reduces the exploit protections for the app itself to be much closer to the stock OS. It makes the app much less protected against being compromised by a remote attacker, although in this case there's probably not a lot of attack surface exposed from arbitrary parties.

Atrate commented 8 months ago

Here is a screen recording using OsmAnd 4.6.11 on a Google Pixel 8. osmand-v4611-pixel8.mp4

Depending on zoom level, render time averages between 2 and 12 seconds.

I know OsmAnd draws a lot of detail, so it's hard to compare. Organic Maps draws screens in the same area mostly under a second.

I can confirm that an extremely similar thing happens on the Fairphone 4 with DivestOS. Legacy is faster than OpenGL.

Redsandro commented 8 months ago

I can confirm that an extremely similar thing happens on the Fairphone 4 with DivestOS. Legacy is faster than OpenGL.

@Atrate I don't know DivestOS, but for GrapheneOS the instructions from @thestinger fixed the problem. Perhaps DivestOS has similar protection modes that can be switched off for OsmAnd.

(...) you should try enabling exploit protection compatibility mode. There's also an individual toggle for hardened_malloc to only disable hardened_malloc while leaving other features like extended address space enabled.

As for this issue and whether or not it should remain open: I don't know what OsmAnd does differently from other map apps, but my hypothesis is as follows:

  1. It can be fixed;
  2. Fixing it incurs a volunteer development cost;
  3. Custom ROMs are a niche;
  4. Disabling strict memory protection circumvents the problem.

I think the problem should be understood and documented, perhaps added to some kind of Kanban or Wish list if it exists, and/or labeled WontFix and closed.

thestinger commented 8 months ago

DivestOS uses our hardened_malloc implementation across many devices along with some other GrapheneOS hardening features. They likely don't implement the per-app toggles. Don't know.

Atrate commented 8 months ago

As far as I can see, there are no per-app toggles for exploit protection compat/hardened malloc in DivestOS. There's only a global "Enable secure app spawning" toggle. Maybe @SkewedZeppelin can shine some more light on the topic.

thestinger commented 8 months ago

@Atrate Note secure app spawning only impacts managed app process spawning time (cold start when it's not a cached app) and increases memory usage per managed app process (not regular processes from native executables). It doesn't hurt runtime performance beyond memory usage being higher.

Piscium commented 5 months ago

Like the OP I have a Pixel 8 running GrapheneOS. Thestinger's suggestion of enabling exploit protection compatibility mode fixed it, so to speak (it made it fast). Thanks.

I will make an extra comment for those testing the effect of enabling exploit protection compatibility mode. After toggling or untoggling the relevant switch on GrapheneOS, force-stop OsmAnd, and call it again (just swiping OsmAnd away is not enough, it seems OsmAnd still lingers in the background).

esatravi commented 3 months ago

I run OsmAnd~ (v. 4.8.5) on Pixel 8 with the latest GrapheneOS (android 14)

Unfortunately no positive effect or improvement has been observed by toggling "exploit protection compatibility mode" or any other changes to security settings.

OsmAnd map rendering is painfully slow (completely unusable actually) when Version 2 (OpenGL) rendering engine is selected. No workaround worked for me.

Version 1 engine rendering speed is passable but still relatively slow.

This is certainly not a hardware/CPU issue as Pixel 8 is a new and pretty strong mobile. The best benchmark for me is Organic Maps - it is literary blazing fast and has got features such as 3D buildings. I run it on my Pixel 8 and no delays with maps rendering is observed whatsoever.

I suspect OsmAnd rendering engine code revision is required in order to remove processing bottlenecks.

DmitryAlexei commented 3 months ago

@esatravi Please provide a short video of your issue and coordinates of that spot

thestinger commented 3 months ago

It should perform as well as it does outside GrapheneOS with the exploit protection compatibility mode toggle enabled but it won't resolve any issue that's present elsewhere. It shouldn't really get much slower when using hardened_malloc though. We could provide more tuning for hardened_malloc performance vs. security settings but that might be an excessive amount of configuration...

Piscium commented 3 months ago

I run OsmAnd~ (v. 4.8.5) on Pixel 8 with the latest GrapheneOS (android 14)

OsmAnd~ on F-Droid is still on v. 4.8.4, where did you get v. 4.8.5?

Unfortunately no positive effect or improvement has been observed by toggling "exploit protection compatibility mode" or any other changes to security settings.

OsmAnd map rendering is painfully slow (completely unusable actually) when Version 2 (OpenGL) rendering engine is selected. No workaround worked for me.

Version 1 engine rendering speed is passable but still relatively slow.

This is certainly not a hardware/CPU issue as Pixel 8 is a new and pretty strong mobile. The best benchmark for me is Organic Maps - it is literary blazing fast and has got features such as 3D buildings. I run it on my Pixel 8 and no delays with maps rendering is observed whatsoever.

I suspect OsmAnd rendering engine code revision is required in order to remove processing bottlenecks.

I am also on Pixel 8 with the latest GrapheneOS (android 14), on v. 4.8.4, and cannot reproduce what you have. With "exploit protection compatibility mode" enabled it seems the same speed with version 1 or 2.

With "exploit protection compatibility mode" disabled it is crashing for me at the start, apparently due to a memory tagging issue..

esatravi commented 3 months ago

@esatravi Please provide a short video of your issue and coordinates of that spot

Here is the video of the slow map rendering in OsmAnd, when rendering engine is set to Version 2 (OpenGL)

https://github.com/user-attachments/assets/cad9d819-7c33-4562-9398-4636f5679d3a

Here, for comparison, rendering speed of Organic Maps, very responsive even with quick zooming in / out

https://github.com/user-attachments/assets/509b6a02-14f4-4175-9ee9-40d2a3bb68c0

esatravi commented 3 months ago

It should perform as well as it does outside GrapheneOS with the exploit protection compatibility mode toggle enabled but it won't resolve any issue that's present elsewhere. It shouldn't really get much slower when using hardened_malloc though. We could provide more tuning for hardened_malloc performance vs. security settings but that might be an excessive amount of configuration...

Thank you for your comments. Unfortunately the experience is slow OpenGL rendering continues across various Pixel phones and GrapheneOS on them - I tried it on Pixel 3, Pixel 5, Pixel 8. OS doesn't get any modifications or google-play installation.

My assumption was that since GrapheneOS is pure/degoogled android it should perform as well as Pixel stock OS. But it doesn't, for reasons unknown to me. I like OsmAnd and use with the Version 1 rendering engine instead.

esatravi commented 3 months ago

I run OsmAnd~ (v. 4.8.5) on Pixel 8 with the latest GrapheneOS (android 14)

OsmAnd~ on F-Droid is still on v. 4.8.4, where did you get v. 4.8.5?

Unfortunately no positive effect or improvement has been observed by toggling "exploit protection compatibility mode" or any other changes to security settings. OsmAnd map rendering is painfully slow (completely unusable actually) when Version 2 (OpenGL) rendering engine is selected. No workaround worked for me. Version 1 engine rendering speed is passable but still relatively slow. This is certainly not a hardware/CPU issue as Pixel 8 is a new and pretty strong mobile. The best benchmark for me is Organic Maps - it is literary blazing fast and has got features such as 3D buildings. I run it on my Pixel 8 and no delays with maps rendering is observed whatsoever. I suspect OsmAnd rendering engine code revision is required in order to remove processing bottlenecks.

I am also on Pixel 8 with the latest GrapheneOS (android 14), on v. 4.8.4, and cannot reproduce what you have. With "exploit protection compatibility mode" enabled it seems the same speed with version 1 or 2.

With "exploit protection compatibility mode" disabled it is crashing for me at the start, apparently due to a memory tagging issue..

I get my OsmAnd~ from f-droid repository: f-droid.org/packages/net.osmand.plus - suing droid-ify app. It is currently on version 4.8.5 (as of 9/8/2024)

Toggling "exploit protection compatibility mode" on or off doesn't effectuate any performance change, or does it crushes the OsmAnd app. I tried the toggle globally (in Settings/Security) or at the app level in its properties.

I run out of ideas how to to enable faster OpenGL mode...

Piscium commented 3 months ago

I get my OsmAnd~ from f-droid repository: f-droid.org/packages/net.osmand.plus - suing droid-ify app. It is currently on version 4.8.5 (as of 9/8/2024)

You are right, it is 4.8.5. because it is the “suggested version” it was not installed by the F-droid app and not shown in the F-droid website at the top (one needs to scroll down quite a bit to show the 4.8.5 version). It is the second time I trip on this.

Toggling "exploit protection compatibility mode" on or off doesn't effectuate any performance change, or does it crushes the OsmAnd app. I tried the toggle globally (in Settings/Security) or at the app level in its properties.

I upgraded to 4.8.5 but also with it it crashes on me due to a memory tagging error if I, while showing the map, with the finger change the centre of the map. It only takes a few seconds of doing so for it to crash. A few months ago when I first installed osmand on the pixel 8 it also crashed, but only once at startup, due to “use after free”. That crash was not repeatable, unlike the current one. If I disable memory tagging then there is no crash.

There is (at least) one difference between your pixel 8 installation and mine: in mine i have installed Google Play. I don't know if that is the reason why we have different results doing the same tests.