Support hardware acceleration in MyLocationOverlay and ScaleOverlay

[GoogleCodeExporter]

This always worked in my code (within main activity onCreate) but crashes the 
app since I updated to 4.0.3 (Virtuous Quattro RC2 rom). 

    this.myScaleBarOverlay = new ScaleBarOverlay(this); 
    this.myMap.getOverlays().add(myScaleBarOverlay);

Now it produces the following: 

01-25 14:53:38.303: E/AndroidRuntime(3263): FATAL EXCEPTION: main
01-25 14:53:38.303: E/AndroidRuntime(3263): 
java.lang.UnsupportedOperationException
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.GLES20Canvas.drawPicture(GLES20Canvas.java:916)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
org.osmdroid.views.overlay.ScaleBarOverlay.draw(ScaleBarOverlay.java:263)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
org.osmdroid.views.overlay.OverlayManager.onDraw(OverlayManager.java:117)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
org.osmdroid.views.MapView.dispatchDraw(MapView.java:821)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.View.getDisplayList(View.java:10415)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.ViewGroup.drawChild(ViewGroup.java:2850)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.ViewGroup.dispatchDraw(ViewGroup.java:2489)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.View.getDisplayList(View.java:10415)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.ViewGroup.drawChild(ViewGroup.java:2850)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.ViewGroup.dispatchDraw(ViewGroup.java:2489)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.View.getDisplayList(View.java:10415)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.ViewGroup.drawChild(ViewGroup.java:2850)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.ViewGroup.dispatchDraw(ViewGroup.java:2489)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.View.getDisplayList(View.java:10415)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.ViewGroup.drawChild(ViewGroup.java:2850)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.ViewGroup.dispatchDraw(ViewGroup.java:2489)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.View.draw(View.java:10981)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.widget.FrameLayout.draw(FrameLayout.java:450)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
com.android.internal.policy.impl.PhoneWindow$DecorView.draw(PhoneWindow.java:212
6)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.View.getDisplayList(View.java:10417)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.HardwareRenderer$GlRenderer.draw(HardwareRenderer.java:871)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.ViewRootImpl.draw(ViewRootImpl.java:1910)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1634)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.view.ViewRootImpl.handleMessage(ViewRootImpl.java:2442)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.os.Handler.dispatchMessage(Handler.java:99)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.os.Looper.loop(Looper.java:137)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
android.app.ActivityThread.main(ActivityThread.java:4424)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
java.lang.reflect.Method.invokeNative(Native Method)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
java.lang.reflect.Method.invoke(Method.java:511)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
01-25 14:53:38.303: E/AndroidRuntime(3263):     at 
dalvik.system.NativeStart.main(Native Method)

Original issue reported on code.google.com by eas...@googlemail.com on 25 Jan 2012 at 1:59

• Merged into: #413

[GoogleCodeExporter]

I haven't yet investigated/tested a fix, but I can tell you that the fix is to 
add this attribute to the activity in the manifest

android:hardwareAccelerated="false"

The reason is that hardware acceleration is enabled by default in 4.* and 
Canvas.drawPicture doesn't support it.

See also
http://android-developers.blogspot.com/2011/03/android-30-hardware-acceleration.
html
https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s

Original comment by neilboyd on 25 Jan 2012 at 2:45

• Changed state: Accepted

[GoogleCodeExporter]

Note that this doesn't effect the demo app because it has 
android:targetSdkVersion="4".
It is only an issue if your app has android:targetSdkVersion="14" or higher.

Original comment by neilboyd on 3 Feb 2012 at 6:21

• Changed state: WontFix

[GoogleCodeExporter]

For future googlers. This issue also affects MyLocationOverlay.drawCompass.

Original comment by jpetti...@gmail.com on 5 Jul 2012 at 9:01

[GoogleCodeExporter]

I will re-open this issue with a new title.

It would be nice if we could remove the usage of drawPicture and thereby 
support hardware acceleration.

Original comment by neilboyd on 6 Jul 2012 at 7:55

• Changed title: Support hardware acceleration in MyLocationOverlay and ScaleOverlay
• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

FYI - I found the maps run very slow using hardware acceleration. From what I 
have read it is because we are doing a lot of canvas drawing operations 
(canvas.drawCircle, drawBitmap, etc...) and that doesn't translate well in 
terms of performance when using the "automatic" hardware acceleration.

Original comment by kurtzm...@gmail.com on 19 Jul 2012 at 8:24

[GoogleCodeExporter]

Issue 339 has been merged into this issue.

Original comment by neilboyd on 30 Oct 2012 at 4:40

[GoogleCodeExporter]

Issue 380 has been merged into this issue.

Original comment by neilboyd on 30 Oct 2012 at 4:41

[GoogleCodeExporter]

This issue has been reported in Google Play on the following devices:
ARCHOS 80G9
LT15i
LT26i
OTHER

I assume these are devices that don't follow the guidelines in the links in 
comment 1.

Original comment by neilboyd on 30 Oct 2012 at 8:15

[GoogleCodeExporter]

I believe we can set hardware acceleration off programmatically at the view 
level. I will try to dig up the code.

Original comment by kurtzm...@gmail.com on 30 Oct 2012 at 9:14

[GoogleCodeExporter]

See comment 1. You should be able to set it in the manifest, but it /should/ be 
unnecessary.

Original comment by neilboyd on 31 Oct 2012 at 7:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

We can add:

this.setLayerType(View.LAYER_TYPE_SOFTWARE, null);

to the MapView constructor to force it to not use hardware acceleration without 
requiring the user to change their manifest. To do that, we need to target a 
higher API (11?) which I am in favor of but others may not be so hot on. 
Perhaps we can use reflection to call it if available and keep it targeted at 
the current API.

Original comment by kurtzm...@gmail.com on 31 Oct 2012 at 7:45

[GoogleCodeExporter]

I don't see the problem with increasing the target version, or the problem with 
changing the manifest.

Original comment by neilboyd on 31 Oct 2012 at 9:22

[GoogleCodeExporter]

Just want to add another comment to this one: people can force GPU rendering in 
the developer options and this will override the 
android:hardwareAccelerated="false" setting in the manifest - making the app 
crash in the end after all. Keen to find out of there is a way of overriding 
the force GPU dev setting. Unfortunately my only ICS device is a Nexus 7 that 
opts to simply ignore drawing of the ScaleBar if force GPU rendering is on so 
that I cannot reproduce the Exception :-(
Also see
https://groups.google.com/forum/?fromgroups=#!topic/android-developers/MDgTz-CYW
mM

Original comment by osei...@gmail.com on 19 Jan 2013 at 7:00

[GoogleCodeExporter]

Adding this into MapView'a constructor helps overriding force GPU rendering
if (Build.VERSION.SDK_INT >= 11 /* Build.VERSION_CODES.HONEYCOMB */) {
  try {
    Method m = View.class.getMethod("setLayerType", int.class, Paint.class);
    m.invoke(this, 0x01/*View.LAYER_TYPE_SOFTWARE*/, null);
  } catch (Throwable t) {
    logger.warn("Exception when trying to invoke this.setLayerType(LAYER_TYPE_SOFTWARE,0)", t);
  }
}

Original comment by osei...@gmail.com on 19 Jan 2013 at 7:23

[GoogleCodeExporter]

I believe we should add this as a default. Maybe add the ability to allow the 
user to turn it on too if they want?

For the MyLocationOverlay - it may be possible to change the drawPicture stuff 
into a path. However, there may be performance differences between the two.

Original comment by kurtzm...@gmail.com on 19 Jan 2013 at 8:45

[GoogleCodeExporter]

See issue 413. When I turn hardware acceleration on the maps turn to buttery 
smooth. Let's make this happen!

Original comment by kurtzm...@gmail.com on 29 Mar 2013 at 2:58

[GoogleCodeExporter]

We currently demo how to programmatically turn off hardware acceleration in the 
samples. The remainder of this ticket has been moved to Issue 413.

Original comment by kurtzm...@gmail.com on 14 Jun 2013 at 2:17

• Changed state: Duplicate

[GoogleCodeExporter]

Hello guys
I use osmdroid 3.0.10 and still getting exception mentioned above on some 
devices. Please, advise me how to fix it.

Original comment by miro.le...@gmail.com on 15 Jul 2013 at 3:16

[GoogleCodeExporter]

I am running into a bug with drawPath overlay. With HW acc on the path 
sometimes does not render depending on the location of the line points. This is 
consistently reproducible. No problem with HW acc off. 

Original comment by vit.hrad...@gmail.com on 26 Jul 2013 at 3:01

[GoogleCodeExporter]

Could you please open a new issue and attach a simple project that exhibits 
this bug.

Original comment by kurtzm...@gmail.com on 26 Jul 2013 at 1:48

[GoogleCodeExporter]

Sure, I created Issue 454. Thanks for taking a look!

Original comment by vit.hrad...@gmail.com on 26 Jul 2013 at 6:29