Confusing handling of native scale layer and "zoom to download"

[GerdP]

What steps will reproduce the problem?

1. Load some data from OSM server
2. Zoom out
3. Press 5 to "zoom to download", note that a small part of the dashed area is still visible
4. Add Bing layer (or another one with a "native scale"), make sure that the "scale follows native resolution ..." checkbox is enabled, note that the dashed area disappeared because JOSM zoomed in a little bit.
5. Remove Bing layer, note that this doesn't change the map view
6. Press 5 again to zoom to download area. Note that now a large dashed area is visible, means, this zoom simply doesn't work anymore. Edit: This is also the case when the layer is not removed.

What is the expected result?

• Not sure if the small "zooom in" in step 4 is intended?
• The layer removal should restore the old behaviour befor that layer was added. So, either enable a previous layer that was used for native scaling or none.

What happens instead?

• "zoom to download" no longer works until I add another layer with "native scale" and disable the "scale follows native resolution ..." checkbox

Please provide any additional information below. Attach a screenshot if possible.

Found this while looking for memory leaks. The field NavigatableComponent.nativeScaleLayer is not modified when the Bing layer is removed.

Build-Date:2020-12-17 10:49:38
Revision:17408
Is-Local-Build:true

Identification: JOSM/1.5 (17408 SVN en) Windows 10 64-Bit
OS Build number: Windows 10 Home 2004 (19041)
Memory Usage: 791 MB / 1820 MB (671 MB allocated, but free)
Java version: 1.8.0_272-b10, AdoptOpenJDK, OpenJDK 64-Bit Server VM
Look and Feel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Screen: \Display0 1920×1080 (scaling 1.00×1.00)
Maximum Screen Size: 1920×1080
Best cursor sizes: 16×16→32×32, 32×32→32×32
VM arguments: [-agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:57460, -ea, -javaagent:D:\eclipse-java-2020-09\eclipse\configuration\org.eclipse.osgi\215\0\.cp\lib\javaagent-shaded.jar, -Dfile.encoding=UTF-8]

Plugins:
+ ColumbusCSV (35640)
+ buildings_tools (35669)
+ o5m (35640)
+ pbf (35650)
+ poly (35640)
+ reverter (35640)
+ undelete (35640)
+ utilsplugin2 (35671)

Validator rules:
+ c:\josm\core\resources\data\validator\geometry.mapcss

[GerdP]

The memory leak should be fixed with this small patch:

src/org/openstreetmap/josm/gui/MapView.java

@@ -397 +397 @@
         ProjectionRegistry.removeProjectionChangeListener(layer);
         layer.removePropertyChangeListener(this);
         invalidatedListener.removeFrom(layer);
+        if(layer == getNativeScaleLayer())
+            setNativeScaleLayer(null);
         layer.destroy();
         AudioPlayer.reset();

We changed the behaviour of the zoom keys so often that I am no longer sure what exactly should happen.

[GerdP]

In 17445/josm:

see #20272: Confusing handling of native scale layer and "zoom to download"

• if imageary layer is removed which was enabled for "scale follows native resolution ..." set the native scale layer to null.

An alternative might be to check if another layer could be enabled, but that would requure more logic and a history.

[GerdP]

I am not sure what to do with the different behaviour when the "scale follows native resolution ..." checkbox is enabled.
At the moment (also with r17445) we have at least three:

1. the zoom that is used when the imageary layer is loaded. This is sometimes too close so that parts of the download area are no longer visible
2. the one that you get when you 5 to "zoom to download": This one seems always too far out.
3. the one that you get when you 5 to "zoom to download" when no "scale follows native resolution ..." checkbox is enabled.

I prefer the last result, so my solution is to use preference zoom.scale-follow-native-resolution-at-load=false.