Default snap distance is too small on modern monitors

[GerdP]

This is a follow up of ticket:18420#comment:2
The hardcoded default 10 pixels was probably OK for monitors with a 800x600 resolution, but today we have much higher resolutions. As a result, actions don't find anything "nearby" unless the users increases the values in the preferences.
I assume we have more such out-aged default values and I wonder if there is a user friendly way to adjust them?
mappaint.node.snap-distance
mappaint.node.virtual-snap-distance
mappaint.segment.snap-distance

[stoecker]

We have already a partial HDPI handling. That can be used to adapt the snap distance as well.

[GerdP]

Replying to stoecker:

We have already a partial HDPI handling. That can be used to adapt the snap distance as well.

Do you mean ticket #9995?

[stoecker]

I think so. But I don't remember current state.😁

[GerdP]

My idea for this:
Collect the preference values which depend on the screen resolution and calculate good defaults based on the actual screen resolution. Present the calculated values in a popup and ask for confirmation to use them.
Repeat this when the resoltion is changed.
Would this work with multi-screen-configurations?

[Don-vip]

Replying to GerdP:

Would this work with multi-screen-configurations?

No idea, needs to be checked for sure.

[stoecker]

Replying to Don-vip:

Replying to GerdP:

Would this work with multi-screen-configurations?

No idea, needs to be checked for sure.

It will probably not. But I think it makes no sense to support HIDPI and normal screens and auto-switching of settings. If java does this from scratch then fine, but JOSM is not the right place to do such a thing. We'll support only one active config.

trunk/src/org/openstreetmap/josm/tools/GuiSizesHelper.java​ is already there to do the calculations. It probably only needs to be used for the snap distances.

I wouldn't ask the user. Choose sensible values instead.

[Don-vip]

Replying to stoecker:

If java does this from scratch then fine, but JOSM is not the right place to do such a thing. We'll support only one active config.

Agreed. Personally I don't take any look to hidpi issues until we switch to Java 11. A lot of stuff has been done in Java 9 and it would be too complex to try to find a working system between Java 8 and Java 11+.

Plus, maybe the day we switch to Java 11 I will have an hidpi screen to test :)

[GerdP]

I am happy with the idea to ignore the existing preference options and calculate reasonable values. If users don't like those values we may add new preference options which use a factor instead of a fixed amount of pixels.

BTW: I've never even worked with multi-screen-configurations or HIDPI monitors

[stoecker]

See e.g. trunk/src/org/openstreetmap/josm/tools/ImageProvider.java#L227​. In this class we use the preferences settings as base value for calculations.

[stoecker]

Replying to GerdP:

BTW: I've never even worked with multi-screen-configurations or HIDPI monitors

Well, if you start with it, you get used to it very fast :-)

[Klumbumbus]

Is screen resoultion sufficient to find a proper value? I mean 4k screens are in use from small tablets/notebooks to large >86" TVs. (Even smartphones with 4k screen exist, but JOSM is probably not used on smartphones anyway). I guess JOSM has no information about the screen size?

[Don-vip]

Replying to Klumbumbus:

I guess JOSM has no information about the screen size?

It does. Look at any bug report ;)

[Klumbumbus]

I don't mean pixels, I mean physical size (diagonal in cm or inch).

[Don-vip]

Ah, no, we don't know that.

[stoecker]

Look again at what GuiSizesHelper does. We may not have this always, but DPI is the equivalent of the physical dimensions.

[GerdP]

Oops, wrong number in patch, but it is really for this ticket.
@Dirk: If I got that right the user should only adapt gui.scale and other preference values like the snap distances should depend on this value?

[stoecker]

Replying to GerdP:

@Dirk: If I got that right the user should only adapt gui.scale and other preference values like the snap distances should depend on this value?

I'd say so (except the case that this approach maybe does not work, but KDE and others have a similar approach and it seems to work).

[GerdP]

We have code like this:

public static final IntegerProperty PROP_SNAP_DISTANCE = new IntegerProperty("mappaint.node.snap-distance", 10);

What do you think about implementing a new class GuiScaledIntegerProperty which does the scaling?

[stoecker]

@Vincent:

What do you think? I actually have no idea what the advantage of the XXXProperty classes is compared to a direct prefs call.

[Don-vip]

Replying to stoecker:

@Vincent:
I actually have no idea what the advantage of the XXXProperty classes is compared to a direct prefs call.

It avoids to specify the preference key multiple times. Other than that, not a lot of differences.

[Don-vip]

I have added a small method to detect if we're running in HIDPI in r15918. Works fine on Mac (with a Retina screen, returns false with Java 8, true with Java 13). It can probably be used for this ticket as well.

[stoecker]

Replying to Don-vip:

I have added a small method to detect if we're running in HIDPI in r15918. Works fine on Mac (with a Retina screen, returns false with Java 8, true with Java 13). It can probably be used for this ticket as well.

Please describe how to check if it works. I then can try on my Linux system.

[Don-vip]

Replying to stoecker:

Replying to Don-vip:

I have added a small method to detect if we're running in HIDPI in r15918. Works fine on Mac (with a Retina screen, returns false with Java 8, true with Java 13). It can probably be used for this ticket as well.

Please describe how to check if it works. I then can try on my Linux system.

You mean this ticket or the small method I wrote? I only copied it from StackOverflow and checked its good behaviour on a macBook: ​https://stackoverflow.com/a/49770313

Comments on StackOverflow:

You could alternatively inspect the scale factor of the transform and check if it is equal to 2 and fall back to non-retina otherwise. The API exists but prior to Java 9 it returns the wrong value: Java 7 and Java 8 use an identity transformation even on Retina displays, and the ScaleX and ScaleY values are always 1.0, regardless of the actual hardware display scale value.

[Don-vip]

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