id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
3928	JOSM slippymap plugin hangs/very slow on first draw on high zoom	morb_au	team	"This is a follow-on from #3878.

I've probed a bit deeper and found the slowness is actually coming from use of the slippymap plugin.

It seems to come from an observation that the default MapView - Epsg4326.getDefaultZoomInPPD() - is about 100 km across in EPSG:4326 projection, and that a paint event is fired *before* the MapView scene has had a chance to be resized (zoomTo) to the last user-zoomed view (e.g. from downloading a very small rectangle of data).  This means it's trying to do an operation (SlippyMapLayer.getTile) across maybe a million or so '''zoom-19''' tiles in the default '''100-kilometre'''-wide view, for no practical reason.  (As it then has to immediately resize the view to only 200m wide or so to fit the just-download data rectangle.)

The slowness effect really shows up if you have just downloaded an area at about zoom 19 or closer.  (Which is now plausible since NearMap is useful to 21-23, and I've hacked my JMapViewer to allow zoom to 21).

As a workaround I've changed Epsg4326.getDefaultZoomInPPD() from returning 0.009 to 0.0000009 (set the scale bar to about 0.0100 km)

Perhaps a more permanent fix is to somehow delay the initial slippymap paint event until the MapView has been given its first zoomTo().  Or give the MapView some extra property to track if it has had a zoomTo already, and slippymap will only actually paint if the property is true.  Or somehow convince SlippyMapLayer.TileSet.allTiles not to enter its for-loops if it will result in iterating over a very large amount of tiles.

I am not a Java programmer nor a JOSM architect, so this is all I could come up with.

JOSM Build: based on r2447, slippymap build: based on 18485."	defect	closed	normal		Core	latest	fixed	slippymap slow hang zoom paint draw tiles nearmap mapview projection defaultzoom