Get hardware acceleration working

[GoogleCodeExporter]

At least two things that must be fixed:

 1. Use of drawPicture(). Hardware acceleration no longer crashes when you try to do this, it just seems to draw nothing.

 2. Fix safe canvas drawing issues. This may hold some answers: https://code.google.com/p/android/issues/detail?id=24517

Original issue reported on code.google.com by kurtzm...@gmail.com on 29 Mar 2013 at 1:39

[GoogleCodeExporter]

Safe canvas drawing and hardware acceleration is fixed in r1189.

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

[GoogleCodeExporter]

Hi kurtzmarc,

The View.getMatrix() is "Added in API level 11".
I see at manifest minSdkVersion="3" but now I cannot compile / run osmdroid 
apps with Android smaller than 11.
Am I missing something?

Thanks.

Original comment by devemu...@gmail.com on 29 Mar 2013 at 10:37

[GoogleCodeExporter]

You're right - I will have to add code to fall back if the API is lower.

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

[GoogleCodeExporter]

Give the trunk a try now.

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

[GoogleCodeExporter]

The "Use system API constants" produces again issues, as the 
Build.VERSION_CODES.HONEYCOMB is also "Added in API level 11".

Original comment by devemu...@gmail.com on 29 Mar 2013 at 4:25

[GoogleCodeExporter]

You need to target API 16, but keep the minimum API at 4.

Original comment by kurtzm...@gmail.com on 29 Mar 2013 at 4:28

[GoogleCodeExporter]

For future reference: 
http://android-developers.blogspot.com/2011/03/android-30-hardware-acceleration.
html

We should check the code for all non-supported operations and replace them.

Original comment by kurtzm...@gmail.com on 29 Mar 2013 at 5:22

[GoogleCodeExporter]

I understand your point but I wish to be able to compile the osmdroid projects 
with SDK < 11 and using same target, like I was doing till now.

Another issue I see with your change at SafeDrawOverlay in r1189 is that at 
devices with Android 2.3 the zoom in/out does not work properly now.
At zoom scale animations the tiles disappear (like moving off screen).

Original comment by devemu...@gmail.com on 29 Mar 2013 at 5:44

[GoogleCodeExporter]

@devemux86 why would you want to set a target sdk < 11?

Original comment by neilboyd on 30 Mar 2013 at 10:21

[GoogleCodeExporter]

I used to compile a specific project with SDK 10 (and use same target) as 
didn't have the time to check for inconsistencies from newer API (such as the 
removal of menu button at >=11 and use of action bar).
But better late than never!

Original comment by devemu...@gmail.com on 30 Mar 2013 at 11:49

[GoogleCodeExporter]

If you use Eclipse then Lint tells you all that stuff.

Original comment by neilboyd on 30 Mar 2013 at 4:08

[GoogleCodeExporter]

The Lint indeed has API check from ADT 17, but for Android projects/libraries.
For a simple java project (but compiled with Android SDK) used as library jar 
(like osmdroid) at an Android application, the Lint cannot be used.
Or there is a way to use Android Lint rules at a java like project?

Original comment by devemu...@gmail.com on 30 Mar 2013 at 5:37

[GoogleCodeExporter]

Hi kurtzmarc,

Have you looked SafeDrawOverlay's change at r1189 and its result at Android 2.3 
devices?
As I mentioned at #8 the zoom in/out does not work properly anymore, the tiles 
at zoom scale animations move outside the screen.
May be the code change has to take place only for Honeycomb versions and beyond?

Thanks.

Original comment by devemu...@gmail.com on 4 Apr 2013 at 6:14

[GoogleCodeExporter]

@devemux86 - That should be fixed in r1190. It should work both pre-Honeycomb 
and post-Honeycomb.

Original comment by kurtzm...@gmail.com on 4 Apr 2013 at 1:23

[GoogleCodeExporter]

Actually it doesn't. At r1190 the only change is the way of getting the matrix 
values.
But at r1189 there were also changes at (now) line 69, where the matrix is no 
more used but the canvas.
The prior code with the matrix works well pre-Honeycomb.

Original comment by devemu...@gmail.com on 4 Apr 2013 at 1:44

[GoogleCodeExporter]

This issue was updated by revision r1199.

Original comment by kurtzm...@gmail.com on 5 Apr 2013 at 12:21

[GoogleCodeExporter]

Give it a try now - also test pinch-to-zoom.

Original comment by kurtzm...@gmail.com on 5 Apr 2013 at 12:22

[GoogleCodeExporter]

This issue was updated by revision r1200.

Fix multi-touch pinch to zoom with hardware acceleration.

Original comment by kurtzm...@gmail.com on 5 Apr 2013 at 12:39

[GoogleCodeExporter]

Thanks kurtzmarc,
Speaking about pre-Honeycomb with safe canvas.

The r1199 fixes the zoom issue but the rotation now does not work correctly. It 
takes place not with the screen center.
If I remove the c.getMatrix(sMatrix) at line 74 and after sMatrix.postTranslate 
put back the sMatrix.preRotate then the rotation plays again. So the working 
code in "else" statement for pre-Honeycomb is:

sMatrix.postTranslate(screenRect.left * sMatrixValues[Matrix.MSCALE_X], 
screenRect.top * sMatrixValues[Matrix.MSCALE_Y]);
sMatrix.preRotate((float) Math.toDegrees(angrad), screenRect.width() / 2, 
screenRect.height() / 2);
c.setMatrix(sMatrix);

Original comment by devemu...@gmail.com on 5 Apr 2013 at 7:17

[GoogleCodeExporter]

About pinch-to-zoom, it does not work at pre-14 devices due to setScrollX and 
setScrollY added in API level 14. I'm referring at MapView lines 1147-1148.

Original comment by devemu...@gmail.com on 5 Apr 2013 at 8:06

[GoogleCodeExporter]

Check the latest trunk. I changed the call to scrollTo which works on older 
devices. Unfortunately I don't currently have any older devices to test with 
and I can't do multi-touch on the emulator so continue to provide feedback for 
multi-touch.

Original comment by kurtzm...@gmail.com on 8 Apr 2013 at 10:21

[GoogleCodeExporter]

Ok I can confirm that the multi-touch works again.
Perhaps you can see also the #19 comment about map rotation at pre-Honeycomb 
devices?
Thanks!

Original comment by devemu...@gmail.com on 9 Apr 2013 at 6:43

[GoogleCodeExporter]

@devemux86 See r1207. Rotation should be working again on pre-Honeycomb devices.

Original comment by kurtzm...@gmail.com on 12 Apr 2013 at 12:27

[GoogleCodeExporter]

@kurtzmarc
Yes rotation works now at pre-Honeycomb devices.
Thanks!

Original comment by devemu...@gmail.com on 12 Apr 2013 at 10:35

[GoogleCodeExporter]

Issue 303 has been merged into this issue.

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

[GoogleCodeExporter]

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

Original comment by miro.le...@gmail.com on 15 Jul 2013 at 4:11

[GoogleCodeExporter]

Turn off hardware acceleration in your manifest or contribute code to fix the 
remaining issues.

Original comment by kurtzm...@gmail.com on 15 Jul 2013 at 4:16

[GoogleCodeExporter]

To update this ticket - I believe the only outstanding issue is:

1. Use of drawPicture() in various overlays.

If you aren't using one of the overlays that uses drawPicture() then you should 
be able to use hardware acceleration. If you find issues, please report them 
here!

Original comment by kurtzm...@gmail.com on 16 Jul 2013 at 6:47

[GoogleCodeExporter]

Issue 449 has been merged into this issue.

Original comment by kurtzm...@gmail.com on 16 Jul 2013 at 6:48

[GoogleCodeExporter]

Thanks, it helped.
I am not thinking about fixing this issue, i am satisfied with the non 
accelerated rendering.
Only guys, please dont release explicitly crashing code.

Original comment by miro.le...@gmail.com on 16 Jul 2013 at 7:52

[GoogleCodeExporter]

Issue 303 has been merged into this issue.

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

[GoogleCodeExporter]

Issue 454 has been merged into this issue.

Original comment by kurtzm...@gmail.com on 2 Aug 2013 at 2:36

[GoogleCodeExporter]

Issue 454 got merged into this.
As far as i know i can't disable hardware acceleration for just one activity, 
but for the complete App. Which isn't an option in my case.
Is there any possibility to fix this? Or if not, any other solution?

Original comment by denishamann on 31 Oct 2013 at 9:23

[GoogleCodeExporter]

Hi,

You can try turn off acceleration at view level. See here:
http://code.google.com/p/osmdroid/source/browse/trunk/OpenStreetMapViewer/src/or
g/osmdroid/MapFragment.java
the setHardwareAccelerationOff method.

Regards.

Original comment by devemu...@gmail.com on 31 Oct 2013 at 9:34

[GoogleCodeExporter]

I have a solution that will move this effort forward. What we can do is mark 
some overlays as non-hardware accelerated. In the case we want to draw one of 
these overlays, we would draw the overlay to an offscreen Bitmap buffer which 
would be wrapped in a Canvas and not be hw accelerated. Then we would draw the 
buffer to the real canvas.

The only downside I see is that each Overlay would have to retain a 
screen-sized Bitmap. Because of the way HW acceleration works we can't reuse 
the same Bitmap for all non-HW accelerated overlays in the same onDraw() cycle. 
HW acceleration builds a drawing list and therefore if we try to 
drawOverlay(backingBitmap)->clearBackingBitmap()->drawOverlay(backingBitmap) 
then only the last drawOverlay() would appear on the screen. We could not clear 
the backing bitmap between drawOverlay() calls but then we lose all "layering" 
if there are HW-accelerated overlays in between. So consequently each non-HW 
accelerated overlay must have it's own backing Bitmap.

But otherwise - this gets the TilesOverlay HW accelerated which is where a 
*huge* chunk of our draw cycles get taken up.

Original comment by kurtzm...@gmail.com on 25 Feb 2014 at 4:11

[GoogleCodeExporter]

Update issue 413.
Add experimental HW acceleration support. Allow individual Overlays to mark
themselves non-HW accelerated. In that case they will be provided a Bitmap
backed Canvas for them to draw to which will then be drawn to the HW accelerated
canvas.
Allow individual Overlays to opt-out of shadow-layer drawing. If an overlay is
non-HW accelerated then this eliminates unnecessary overhead and provides a
performance boost.

Original comment by kurtzm...@gmail.com on 25 Feb 2014 at 10:43

[GoogleCodeExporter]

Hi kurtzmarc,

At Overlay class in onDraw method at line 152 you have a check:
c.getWidth() != c.getWidth()
probably meaning:
mBackingBitmap.getWidth() != c.getWidth()

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

Original comment by devemu...@gmail.com on 26 Feb 2014 at 7:36

[GoogleCodeExporter]

@devemux86 Thanks for that catch! Fixed.

Original comment by kurtzm...@gmail.com on 26 Feb 2014 at 3:02

[GoogleCodeExporter]

This issue was updated by revision r1439.

Change the getCanvasIdentityMatrix() to be invertCanvas() which works with both 
HW accelerated and non-HW accelerated.
Replace use of Picture with a Bitmap in CompassOverlay. This makes it 
HW-acceleration compatible. Make it inherit from Overlay since it doesn't need 
a safe canvas.
Change the way we handle getUnsafeCanvas() when using HW-acceleration.

Original comment by kurtzm...@gmail.com on 26 Feb 2014 at 11:18

[GoogleCodeExporter]

Hi,

Testing the latest update:

- At CompassOverlay lines 199-200 you have fixed azimuth and compassEnabled, I 
guess for debug reasons?

- The compass needle is not drawn smooth with antialiasing

- At Android 2.3 the compass zooms in / out together with the map

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

Original comment by devemu...@gmail.com on 27 Feb 2014 at 10:36

[GoogleCodeExporter]

1. Ack! Fixed.

2. What do you mean here? Should we use a Paint object with AA turned on for 
drawing?

3. I seem to recall that it always has done that. Does it do it when two-finger 
pinch-to-zooming?

Original comment by kurtzm...@gmail.com on 27 Feb 2014 at 1:59

[GoogleCodeExporter]

2. Yes, using a Paint like the following at canvas.drawBitmap has much better 
result.
private final Paint smoothPaint = new Paint(Paint.FILTER_BITMAP_FLAG);

3. You are right, at two-finger pinch-to-zoom it doesn't do it.
Only with zoom buttons.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

Original comment by devemu...@gmail.com on 27 Feb 2014 at 2:22

[GoogleCodeExporter]

Added bitmap filtering...

Original comment by kurtzm...@gmail.com on 27 Feb 2014 at 3:40