MyLocationOverlay leaves traces of direction arrow after r1121

[GoogleCodeExporter]

What steps will reproduce the problem?
1. I'm using another than the default icon for the MyLocation direction arrow 
(direction_arrow.png)
2. Turn off follow location, make sure the direction arrow is visible and move 
around. Make sure to move in different direction so that the arrow rotates.
3. See traces left behind on screen shot

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

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

Please provide any additional information below.
The more conservative refresh for MyLocationOverlay calculates the direction 
arrow bounds not correctly. If you use an icon that is not perfectly quadratic 
it will be painted outside the calculated boundary.

See attached patch for a fix.

Original issue reported on code.google.com by osei...@gmail.com on 10 Oct 2012 at 10:34

Attachments:

• device-2012-10-11-094907.png
• MyLocationOverlay.java.patch

[GoogleCodeExporter]

So the issue arises when a non-square icon is used and subsequently rotated - 
we need to invalidate the entire possible area around the center point that the 
rotated icon could fall on. Actually if that's the case, we would need to 
enlarge it by even more since a rotated rectangle bounds can be larger than the 
original. If my thinking is correct - then the invalidate rectangle would be a 
square with sides that equal the length of the diagonal of the original icon.

So if we have an icon that is 12x16. The diagonal would be sqrt(12^2+16^2) = 
20. So the invalidate square would be 20x20.

Just one question - why is the offset multiplied by Math.sqrt(2) in your patch?

Original comment by kurtzm...@gmail.com on 22 Oct 2012 at 7:49

[GoogleCodeExporter]

x*Math.sqrt(2) is the length of the diagonal in a square of length x (special 
quadratical case of your equation above).
I was assuming that the location icon is mostly close to a square and used 
sqrt(2)*the longest icon side. This will ensure that it will always cover the 
area used by the rotated icon (though potentially a minimal fraction more for 
non-squares).
Now, if we enlarge the area to be invalidated we must also tweak the offset, 
because originally the offset uses the centre of the icon, it now must use the 
centre of the slightly larger invalidation area. Multiplying the offset with 
sqrt(2) does that (i.e. makes sure the offset is as much as the centre of the 
enlarged area). If the offset is not tweaked to the larger area size, traces of 
the rotated icon will still stick out.

Original comment by osei...@gmail.com on 22 Oct 2012 at 8:08

[GoogleCodeExporter]

Just to clarify: I'm pretty sure the issue occurs with square icons as well, as 
long as they are not transparent in the far corners.

Original comment by osei...@gmail.com on 22 Oct 2012 at 8:09

[GoogleCodeExporter]

I believe then all we would have to do is offset by widestEdge/2. The rectangle 
starts at the x,y of your present location (posx, posy), we set a width and 
height of widestEdge, and then we center on the x,y where the center of the 
icon will be drawn. Basically we want the invalidate rectangle (square) to be 
centered on posx, posy. Sound correct?

Original comment by kurtzm...@gmail.com on 25 Oct 2012 at 12:06

[GoogleCodeExporter]

Final patch would look like:

            // Get a square bounding box around the object, and expand by the length of the diagonal
            // so as to allow for extra space for rotating
            int widestEdge = (int) Math.ceil(Math.max(DIRECTION_ARROW.getWidth(),
                    DIRECTION_ARROW.getHeight())
                    * Math.sqrt(2));
            reuse.set(posX, posY, posX + widestEdge, posY + widestEdge);
            reuse.offset((int) widestEdge / 2, (int) widestEdge / 2);

Original comment by kurtzm...@gmail.com on 25 Oct 2012 at 12:39

[GoogleCodeExporter]

You're right, spot on.

Original comment by osei...@gmail.com on 25 Oct 2012 at 12:43

[GoogleCodeExporter]

Fixed in r1126. Give it a try and if it works for you, please close the ticket. 
Thanks for the help with this ticket!

Original comment by kurtzm...@gmail.com on 25 Oct 2012 at 1:05

[GoogleCodeExporter]

Gave it a quick test and the location icon seems to be fine now.
But now there are issues with the accuracy circle. I'll attache some 
screenshots here, please move to another issue if you think it should be 
covered under a separate one.

Original comment by osei...@gmail.com on 25 Oct 2012 at 5:07

[GoogleCodeExporter]

In this one the accuracy circle is cut off on the right and top edge.

Original comment by osei...@gmail.com on 25 Oct 2012 at 5:09

Attachments:

• device-2012-10-25-170451.png

[GoogleCodeExporter]

Accuracy circle leaving traces.

Original comment by osei...@gmail.com on 25 Oct 2012 at 5:09

Attachments:

• device-2012-10-25-170536.png

[GoogleCodeExporter]

The black line is a glitch at the previous location.

Original comment by osei...@gmail.com on 25 Oct 2012 at 5:10

Attachments:

• device-2012-10-25-171005.png

[GoogleCodeExporter]

The 3 previous screen shots happened at full zoom, each occured a few times but 
not always. I didn't see them on a lower zoom level, but I had only about 8 
minutes on the ferry to try.
I'll have a look at the code and try to get more samples, but it can take a wee 
while.

Original comment by osei...@gmail.com on 25 Oct 2012 at 5:13

[GoogleCodeExporter]

Okay - I suspect that the accuracy circle might not be accounting for stroke 
width so it's a little short. Your ferry ride is a great debug tool :)

Original comment by kurtzm...@gmail.com on 25 Oct 2012 at 2:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Another ferry ride later and a few (random) thoughts.
- It doesn't only seem to be an issue with invalidation. If you look at the 
first screenshot, there is something missing from the accuracy circle in the 
first place. Not sure if that only occurs after r1121 or was there previously.
- I have artificially enlarged the accuracy circle, but I can still only 
observe this behaviour at the highest zoom level and one below. All other seem 
to be fine.
- When I turn on the mini map and zoom in the rect  angle around the mini map 
wiggles around a bit when moving. See screen shots below. This might be a 
rounding issue and looks somewhat similar to the device-2012-10-25-171005 
screen shot. I'm curious if there is a common reason behind the mini map border 
and the behaviour described here.
- Is it possible that due to anti aliaising the actual accuracy circle drawn is 
larger than radius+stroke width? I've been through the code and applying the 
stroke width in getMyLocationDrawingBounds seems to be fine.

Original comment by osei...@gmail.com on 26 Oct 2012 at 3:10

Attachments:

• device-2012-10-26-155851.png
• device-2012-10-26-155904.png

[GoogleCodeExporter]

Also, has anyone else noticed the circle isn't always round? 

Original comment by osei...@gmail.com on 26 Oct 2012 at 3:16

Attachments:

• device-2012-10-26-161458.png

[GoogleCodeExporter]

What zoom level are you at? You are probably experiencing Issue 221. I 
typically start seeing it at zoom level 19+. There is a patch in the ticket 
that I would like to commit to the trunk but it really could use some testing.

Original comment by kurtzm...@gmail.com on 26 Oct 2012 at 3:35

[GoogleCodeExporter]

Levels 18 and 19. I'll have a look at 221

Original comment by osei...@gmail.com on 26 Oct 2012 at 4:06

[GoogleCodeExporter]

Not sure if the traces are related to 221, but certainly the mini map overlay 
issues look similar. I'll try the patch when I find some time.

Original comment by osei...@gmail.com on 26 Oct 2012 at 4:24

[GoogleCodeExporter]

I've applied the patch from 221, but the same issues remain (accuracy circle 
cut, leaving traces and also the wobbly minimap overlay) :-(

Any other ideas?

Original comment by osei...@gmail.com on 1 Nov 2012 at 3:35

[GoogleCodeExporter]

I saw able to reproduce your problem, and it is related to 221 but the 
MyLocationOverlay hasn't been migrated to the new SafeDrawOverlay base class in 
the patch. Once I did that, the drawing anomalies stopped appearing.

To do this yourself - you will need to change the MyLocationOverlay as follows:

 1. Extend SafeDrawOverlay instead of Overlay
 2. Change the draw() method to be the safeDraw() method.
 3. Change all Paint objects to be SafePaint objects.

If I get a chance, I'll post a new patch to 221. At some point I am actually 
going to rewrite MyLocationOverlay and split it into two classes - one for 
MyLocation and one for the compass, and they will be much more modular so you 
can provide locations and bearings from sources other than the GPS. That class 
will use the safe drawing methods.

Original comment by kurtzm...@gmail.com on 1 Nov 2012 at 6:15

[GoogleCodeExporter]

Sorry, my bad. I thought I had seen MyLocationOverlay in the patch, but that 
must have been wishful thinking. Will update MyLocationOverlay and try again.

Original comment by osei...@gmail.com on 1 Nov 2012 at 6:35

[GoogleCodeExporter]

Issue 383 has a new MyLocationOverlay class that uses SafeDrawOverlay if you'd 
like to try. I'm sorry everything is in patches right now, but I will 
eventually apply them all to the trunk once we get more testing done.

Original comment by kurtzm...@gmail.com on 5 Nov 2012 at 2:47

[GoogleCodeExporter]

Thanks, I had done this myself last week and it looks good. Haven't had a 
chance to give it much testing, but I think you nailed it.
Do you want to close this issue and link it to Issue 221 and Issue 383 ?

Original comment by osei...@gmail.com on 5 Nov 2012 at 5:10

[GoogleCodeExporter]

Committed new MyLocation overlay in r1138. This ticket can now be closed.

Original comment by kurtzm...@gmail.com on 3 Jan 2013 at 7:50

• Changed state: Fixed