Opened 15 years ago
Closed 15 years ago
#3928 closed defect (fixed)
JOSM slippymap plugin hangs/very slow on first draw on high zoom
| Reported by: | morb_au | Owned by: | team |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Core | Version: | latest |
| Keywords: | slippymap slow hang zoom paint draw tiles nearmap mapview projection defaultzoom | Cc: |
Description
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.
The slippymap code has some checks that prevent it from *drawing* when the current area is more than 10 tiles across. But, you're right. It still iterates over these tile numbers. When there are a couple thousand in each direction, this really adds up.
I've committed some changes to svn that should make this quite a bit better. You won't get *any* tiles drawn on screen once you get more than 10,000 visible, but I think that's tolerable.