Modify

Opened 5 months ago

Last modified 3 months ago

#18457 new enhancement

Default snap distance is too small on modern monitors

Reported by: GerdP Owned by: team
Priority: normal Milestone:
Component: Core Version:
Keywords: hidpi snap Cc:

Description (last modified by Klumbumbus)

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

Attachments (1)

18420.patch (1.3 KB) - added by GerdP 5 months ago.

Download all attachments as: .zip

Change History (28)

comment:1 Changed 5 months ago by stoecker

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

comment:2 Changed 5 months ago by Klumbumbus

Description: modified (diff)

comment:3 in reply to:  1 Changed 5 months ago by 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?

comment:4 Changed 5 months ago by stoecker

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

comment:5 Changed 5 months ago by Don-vip

Keywords: hidpi added

comment:6 Changed 5 months ago by Don-vip

Keywords: snap added

comment:7 Changed 5 months ago by 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?

comment:8 in reply to:  7 ; Changed 5 months ago by Don-vip

Replying to GerdP:

Would this work with multi-screen-configurations?

No idea, needs to be checked for sure.

comment:9 in reply to:  8 ; Changed 5 months ago by 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.

comment:10 in reply to:  9 Changed 5 months ago by 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 :)

comment:11 Changed 5 months ago by 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

comment:12 Changed 5 months ago by 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.

comment:13 in reply to:  11 Changed 5 months ago by 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 :-)

comment:14 Changed 5 months ago by 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?

comment:15 in reply to:  14 Changed 5 months ago by Don-vip

Replying to Klumbumbus:

I guess JOSM has no information about the screen size?

It does. Look at any bug report ;)

comment:16 Changed 5 months ago by Klumbumbus

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

comment:17 Changed 5 months ago by Don-vip

Ah, no, we don't know that.

comment:18 Changed 5 months ago by stoecker

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

Changed 5 months ago by GerdP

Attachment: 18420.patch added

comment:19 Changed 5 months ago by 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?

comment:20 in reply to:  19 Changed 4 months ago by 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).

comment:21 Changed 4 months ago by 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?

comment:22 Changed 4 months ago by 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.

comment:23 in reply to:  22 Changed 3 months ago by 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.

comment:24 Changed 3 months ago by 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.

comment:25 in reply to:  24 ; Changed 3 months ago by 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.

comment:26 in reply to:  25 Changed 3 months ago by 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.

comment:27 Changed 3 months ago by Don-vip

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to GerdP
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.