[patch] Map turn white while zooming in

[Fabi2]

1. Started the latest tested (r1981) with all Plugins disabled.
2. Downloaded half of the city Greifswald in Germany from the server Zoom is at 573 m and upper left map corner at the zoom slider is white (see Screenhot 1)
3. Scrolled in 1 tick with the mouse and got Screenshot 2
4. Scrolled in 1 tick further and the whoole map turns white

Bug seems to be associated with ​http://josm.openstreetmap.de/ticket/3016
This is no deep zooming but the sli

Memory Usage: 369 MB / 3111 MB (201 MB allocated, but free)
Java version: 1.6.0_0 (OpenJDK on Linux)

[Fabi2]

Screenshot 1

[Fabi2]

Screenshot 2

[Fabi2]

Used Request: ​http://api.openstreetmap.org/api/0.6/map?bbox=13.401947021484375,54.06099995171849,13.4527587890625,54.10611237685854

[anonymous]

I did another restart and noticed that the count of mouse wheel ticks needed to get Screenshot 2 is from Screenshot 1 seem to differ. Now needed 3 ticks of zooming in to get Screenshot 2.

[plaicy]

I can not reproduce it. Do you always get the same results? Are the results the same for jvm of sun?

[anonymous]

More info:
I use OpenJDK (​http://openjdk.java.net/) on Linux x86_64 (Debian Lenny) which is based on the Sun JKDK.

$ dpkg -l |grep jdk
ii openjdk-6-jdk 6b11-9.1+lenny2 OpenJDK Development Kit (JDK)
ii openjdk-6-jre 6b11-9.1+lenny2 OpenJDK Java runtime, using Hotspot JIT

On the last tested JOSM (and some tested latest versions) the same JDK worked mostly without problems and only had the described behaviour when zoomed in far to under 1 m, so it may be not only a JDK problem. Now with the latest josm-tested I have this bug direct after downloading. After downloading

​http://api.openstreetmap.org/api/0.6/map?bbox=12.915802001953125,54.12945489870697,12.96661376953125,54.152784276412554 I now direct got a whole white map. For this bbox my 2nd try had the same result.

The how far i can zoom in depends on the size of the bounding box as i now found out. For ​http://api.openstreetmap.org/api/0.6/map?bbox=13.0517578125,54.132874681145694,13.272514343261719,54.18795459374365 i can zoom in a little bit further and initially only get the white left upper corner of the map,

With the Sun JDK:
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode)

everything works as expected for ​http://api.openstreetmap.org/api/0.6/map?bbox=13.401947021484375,54.06099995171849,13.4527587890625,54.10611237685854

[Fabi2]

Maybe it is a rounding or value overflow problem, as I get also a white map, when zooming out very far, at teast for ​http://api.openstreetmap.org/api/0.6/map?bbox=13.0517578125,54.132874681145694,13.272514343261719,54.18795459374365 with OpenJDK.

[anonymous]

I get similar artifacts. See #3323

[Mursti]

I get similar behavior on my Debian Lenny too.

One interesting thing that doesn't seem to be reported is that when the drawing area is white the "height slider" values increase to RIGHT and decrease to LEFT.

So when I slide the slider from right to left the value is 150 and goes down as I slide to right. Then suddenly around 94 the map gets painted and the slider values start increasing again as I go "higher".

[riechfield]

I've got the same problem; but only on my Ubuntu, OpenJDK

I tested various josm snapshot-versions.
It first appears in version 1823.

Maybe this helps to find the error.

[stoecker]

Ticket #3323 has been marked as a duplicate of this ticket.

[xeen]

This is an OpenJDK bug. I added a workaround so OpenJDK stops drawing to random places. Tested with java-6-openjdk and java-6-sun-1.6.0.14. Please note that the drawing area will still turn white if zoomed in further than "< 1 m" but this is not related. (well, maybe it's the same OpenJDK bug, but it's not caused by drawing the world borders)

[xeen]

work around unicode not being supported

[stoecker]

The patch is not correct. When you draw a line you need to calculate the point where it crosses the border. The lines are not vertical or horizontal only (no longer since we have more projections).

[stoecker]

Maybe the whole code should be improved. It usually will draw lots of lines which aren't visible at all.

[xeen]

Ah, I see… it probably would be nice to have at least some idea about all the projection, coordinates and so on. I'll see if I can fix this taking your remark into account. Which projection would be suitable to test this with?

[xeen]

While at it… I guess I cannot assume that the "left border" will always be drawn from bottom to top, can I?

[stoecker]

With UTM you get a nice oval.

Regarding left border - I do not know. If we introduce projections for north or south pole I doubt you can assume anything.

[timo.lindfors@…]

Has this been reported to openjdk developers?

[xeen]

I'm not sure, but you can find a couple of patches affecting Graphics2D that supposedly have been checked into the OpenJDK-7 tree. I haven't had the time to check more closely, so feel free to investigate and open a bugreport for openjdk.

[xeen]

hopefully the OpenJDK has proper Area.intersect support :)

[xeen]

If this patch works, it was actually easier than I thought. Rendering the borders and drawing an empty map takes about 3-5ms, depending on how much zoomed in you are. It gets slower the more you zoom in though, haven't tested if it's slower than without that area intersection stuff.

[xeen]

unused imports must die!

[Bürste]

Ticket #3451 has been marked as a duplicate of this ticket.

[stoecker]

(In [2107]) close #3313 - patch by xeen - fix display problems with OpenJDK (hopefully)