SafeDrawOverlay scrolls/zooms incorrectly in Android 2.3

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create an application containing a MapView. For best results, put a 
PathOverlay in frame.
2. Run the application on Android 2.3 (API 10).
3. Touch-to-scroll (or zoom).

What is the expected output? What do you see instead?

1. The scrolling should match finger speed. It does not.
2. The scrolling of the map should match the scrolling of the PathOverlay. It 
does not - the overlay appears to move independently of the map tiles.

It is clear that the overlay is moving correctly (i.e. at finger speed), while 
the map tiles are moving too fast.

Similar problems with zooming can be observed.

What version of the product are you using? On what operating system?

The problem can be reproduced on the stock API 10 armeabi emulator image.

Please provide any additional information below.

The problem seems to happen within SafeDrawCanvas - calling 
MapView.setUseSafeCanvas(false) makes the problem go away (apart from 
introducing floating-point distortion, obviously).

The problem does not appear to occur in Honeycomb or above. I therefore believe 
that it is caused by the version-specific code within SafeDrawOverlay.draw().

This code seems to have its origins in work that was done to fix issue 413. 
However, my first-cut attempt to reverse the changes (i.e. take it back to 
before r1189 - for this code path only) by replacing preTranslate() with 
postTranslate() and scaling by the MSCALE_X and MSCALE_Y matrix entries seems 
to have made no difference.

Original issue reported on code.google.com by msida...@gmail.com on 5 Sep 2013 at 9:32

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The problems I am encountering seem to be the same as those identified in 
Android issue 24517 (https://code.google.com/p/android/issues/detail?id=24517) 
and worked around in osmdroid issue 413 for post-Honeycomb versions. However, I 
am encountering these problems (a) with recent versions of osmdroid, and (b) on 
Gingerbread/Android 2.3/API 10.

Maybe there is some hardware acceleration (or something else) happening on 
newer, updated versions of Gingerbread, causing getMatrix() and setMatrix() not 
to work as expected?

Original comment by msida...@gmail.com on 6 Sep 2013 at 2:36

[GoogleCodeExporter]

As far as I can tell, the only justification for doing this in pre-Honeycomb 
using getMatrix()/setMatrix() instead of directly using translate() as in 
post-Honeycomb is the unavailability of getScaleX() and getScaleY() in 
pre-Honeycomb. However, if I understand them correctly, these methods are only 
relevant in cases where the corresponding setters - setScaleX()/setScaleY() - 
have been called. I don't see how they could know anything about calls to 
Canvas.scale(), seeing as these calls don't even seem to be recorded reliably 
in the software matrix, let alone in dedicated variables. In any case, the 
translate() solution, sans calls to getScaleX()/getScaleY(), seems to make 
everything work just fine in pre-Honeycomb.

Here is a patch. There are still some strange "jumping" effects during the 
animations when zooming using the zoom buttons or by double-tapping, but 
functionally it seems okay. (Which is better than it was before.)

Original comment by msida...@gmail.com on 6 Sep 2013 at 3:40

Attachments:

• osmdroid-issue474-patch1.patch

[GoogleCodeExporter]

Hi,

Regarding the strange jumps effects at API <11 during the animations at zooming 
using the zoom buttons or double tapping, they seem to be result of the changes 
described at issue #453.
http://code.google.com/p/osmdroid/issues/detail?id=453#c27

Regards.

Original comment by devemu...@gmail.com on 6 Sep 2013 at 5:21

[GoogleCodeExporter]

Okay, well, as far as I am concerned those jump effects are not directly 
relevant to this issue, so they can be fixed either as part of issue 453 or in 
a new issue. The main point of this issue was to make the map render correctly 
on API 10, and that has been achieved.

Original comment by msida...@gmail.com on 7 Sep 2013 at 5:26

[GoogleCodeExporter]

In addition to the "jump" effects while zooming, there is sometimes (but 
according to no consistent pattern) a noticeable translation in map position 
after a pinch-to-zoom event.

However, again, this is subsidiary to the problem that has been solved here 
(and not necessarily related to my problem or its patch).

Original comment by msida...@gmail.com on 7 Sep 2013 at 5:54

[GoogleCodeExporter]

Hi,

I want to notice that I use osmdroid at API <11 with various overlays (also 
PathOverlay) and have not experienced the incorrect behavior you describe.
I'm using the latest trunk without modifications.
Need to do anything special to see the described behavior?

Regards.

Original comment by devemu...@gmail.com on 7 Sep 2013 at 6:08

[GoogleCodeExporter]

As far as I know, there is nothing special that you need to do. Make sure your 
android SDK is all up-to-date, and you have the latest API 10 image installed. 
Create a new AVD with API 10 and an SD card. Create a new project, set the 
target to Android 10 (I have also tested compiling with Android 16), put trunk 
osmdroid and slf4j jars into libs, create a new MapView programmatically with 
"new MapView(this, null)", and set it as the content view. Install into the 
emulator, click and hold the mouse button on a recognisable landmark (such as 
the British Isles), drag across to the side of the emulator screen. Keep the 
mouse button held down. The landmark will no longer be underneath the mouse 
pointer.

I think the fact that my patch does anything at all demonstrates that the 
problem is real.

Original comment by msida...@gmail.com on 9 Sep 2013 at 9:28

[GoogleCodeExporter]

A few things:

1. The target API must be at least 16 for both osmdroid (if you're compiling it 
yourself) and your project. You can set the minSdk to as low as 4.

2. I cannot reproduce your issue as you describe it in comment 13. I create an 
API 10 emulator, install the OpenStreetMapViewer demo and drag from one end of 
the screen to the other. The spot I start my finger at is where it ends up. You 
mention a PathOverlay in the original issue report - is that a necessary part 
anymore? Also, have you reproduced this on actual hardware?

3. I believe you are correct about not needing to use getScaleX() and 
getScaleY(). We could apply the patch you provided to simplify that section of 
code. However, as far as I can tell it is a non-change. The effect should be 
the same. So I'd like to reproduce the problem first and then examine the 
effects of the change before committing it.

Thanks for all the detailed info - BTW, I definitely see the zoom "jumping" 
issue

Original comment by kurtzm...@gmail.com on 10 Sep 2013 at 12:12

[GoogleCodeExporter]

Doh! I hadn't set the API versions in the Android manifest. (I thought I only 
had to set the SDK target - i.e. what the "create project" tool puts into 
project.properties.) It's okay now. Sorry for wasting your time.

For future reference, the issue can be reproduced in OpenStreetMapViewer if you 
comment out the <uses-sdk> and <supports-screens> tags.

Original comment by msida...@gmail.com on 12 Sep 2013 at 4:49

[GoogleCodeExporter]

I think it might be a good idea to make a small change to the "Prerequisites" 
page. Currently it has:

  Manifest additions

      You should be targeting the latest API in your project. We support compatibility back to API 4. 

I would add:

      Note that if your manifest does not have a valid <uses-sdk> tag, maps may display incorrectly on some versions of Android. The following is recommended:

        <uses-sdk android:targetSdkVersion="16" android:minSdkVersion="4" />

Original comment by msida...@gmail.com on 12 Sep 2013 at 5:56

[GoogleCodeExporter]

Thanks for reporting back what you found - this is helpful for diagnosing 
future issues like this. I have updated the prereqs page to note the required 
uses-sdk tag. I am going to spin off your getScaleX/Y() comments into another 
issues since they are correct and help to simplify that piece of code.

Original comment by kurtzm...@gmail.com on 13 Sep 2013 at 2:52

[GoogleCodeExporter]

Original comment by kurtzm...@gmail.com on 13 Sep 2013 at 2:56

• Changed state: Invalid