Mouse pointer target offset

[anonymous]

In 3840 x 2160 resolution I see that pointer and real target "point" is not exactly same place (bit up-left from cross hair center).
This is not big issue, but slows down a bit as need to re-adjust some points.

[bastiK]

Please reopen if this is still an issue with Java 9.

[thomas.barris@…]

Replying to bastiK:

Please reopen if this is still an issue with Java 9.

Java 9 here. I have the same issue with several monitor constellations but all with highDPI. Right now with built-in display of a Surface Pro. Just tested Paint and there is no issue between position pointed to and position of a point painted.
The mouse offset to left-up is in all JOSM modes: selecting, drawing etc. and really annoying as you misclick quite often.

Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2018-07-29 00:41:59 +0200 (Sun, 29 Jul 2018)
Revision:14066
Build-Date:2018-07-29 01:32:17
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (14066 de) Windows 10 64-Bit
OS Build number: Windows 10 Pro 1803 (17134)
Memory Usage: 413 MB / 2048 MB (80 MB allocated, but free)
Java version: 9.0.1+11, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 2736x1824
Maximum Screen Size: 2736x1824
Dataset consistency test: No problems found

Plugins:
+ buildings_tools (34212)
+ terracer (34109)

[Don-vip]

Java 9 is no longer supported. Please try with Java 10.

[thomas.barris@…]

here we go, but it did not change anything.

Relative:URL: ^{/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2018-07-29 00:41:59 +0200 (Sun, 29 Jul 2018)
Revision:14066
Build-Date:2018-07-29 01:32:17
URL:https://josm.openstreetmap.de/svn/trunk}

Identification: JOSM/1.5 (14066 de) Windows 10 64-Bit
OS Build number: Windows 10 Pro 1803 (17134)
Memory Usage: 308 MB / 2048 MB (116 MB allocated, but free)
Java version: 10.0.2+13, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 2736x1824
Maximum Screen Size: 2736x1824
Dataset consistency test: No problems found

[Don-vip]

Can you please attach a screenshot with native resolution? I need to see how JOSM is rendered on your Surface Pro pixel by pixel.

[thomas.barris@…]

JOSM screenshot in native solution

[thomas.barris@…]

screenshot attached as per request

[Don-vip]

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

[Don-vip]

I can reproduce with the following steps:

• close JOSM if running
• change scale factor to 175% on main display (not secondary screen)
• In the Advanced scaling page, enable the option ​'Fix scaling for apps'
• start JOSM on main display

Problem occurs both with 8u192 and 11.0.1

[Don-vip]

In 14342/josm:

see #9995, see #13173 - adjust symbol shapes size based on current DPI

[Don-vip]

@Thomas: please try with r14342, I think the problem should be solved for you. If not please attach a new screenshot showing how it behaves when you create a node
@Basstoelpel: I don't think it will work for you, but it's worth a try too. Just a question: why do you scale your screen to 200%?

[mani100]

I have a 32" 4k-Monitor, Windows10 scale 150% (how I do: my eyesight is bad).
JOSM 14375 java 1.8.0-191

Same problem with the node:

15.07.2020: My problem is fixed in Josm 16538 - thank you

[johsin18]

JOSM works very well now on my HiDPI display, running on Windows 10.

However, I can still reproduce this little issue, even with JOSM revision 15592 and the latest JDK 14 Early Access.

The root cause seems to be this Java bug: ​https://bugs.openjdk.java.net/browse/JDK-8158776
(Unfortunately, I see no way to even comment on that one as a non-member.)

One workaround is to set the the scaling to "System" or "System (Advanced)" in the Windows program properties, but then you don't benefit from the HiDPI resolution anymore.

I have a patch for JOSM that works around this Java bug and fixes the problem, but I'm not sure it is portable. Who volunteers to test this and/or other potential fixes on his platform with varied settings (in particular MacOS, and also Linux)?

[johsin18]

Patch 1

[johsin18]

I have added a patch that fixes the problem. As I cannot test on other platforms, I restricted the change in behavior to Windows.

[johsin18]

I have filed another bug to Java for this problem:
​https://bugs.openjdk.java.net/browse/JDK-8238734

As it contains sample code in contrast to the old bug, they seem to be willing to fix the problem soonish (with Java 15).
My proposed patch would introduce the problem in the opposite direction if it was fixed on the Java side once. So I withdraw it hereby.
A forward-compatible patch (involving getBestCursorSize) would be possible, but is it worth it still?

[Don-vip]

Replying to johsin18:

I have filed another bug to Java for this problem:
​https://bugs.openjdk.java.net/browse/JDK-8238734

Thanks a lot for creating this issue! I have a few questions/remarks:

• I don't understand why you state the issue has been introduced in Java 9? The original Java bug, and this ticket, have been created against Java 8.
• For next issues you can ask to Oracle to add the "josm-found" label. It allows to find JOSM-related issues in JBS.

A forward-compatible patch (involving getBestCursorSize) would be possible, but is it worth it still?

If you can find a way to fix the bug with or without the Java correction, it is worth it. Java versions fragmentation is a reality, it will takes years before we switch from Java 11 to Java 17 (we're still blocked at 8).

[johsin18]

Replying to Don-vip:

• I don't understand why you state the issue has been introduced in Java 9? The original Java bug, and this ticket, have been created against Java 8.

I haven't stated that, but some Oracle employee. But indeed, my sample program works correctly on Java 8u241.
Anyway, HiDPI is supported only from Java 9 really, isn't it? So that's what I care about.

• For next issues you can ask to Oracle to add the "josm-found" label. It allows to find JOSM-related issues in JBS.

I will.

A forward-compatible patch (involving getBestCursorSize) would be possible, but is it worth it still?

If you can find a way to fix the bug with or without the Java correction, it is worth it.

Okay, I will give it a try.

Java versions fragmentation is a reality, it will takes years before we switch from Java 11 to Java 17 (we're still blocked at 8).

You mean we have to stay compatible to Java 8? But the users are free to install a later version, aren't they? For HiDPI, IMHO we should recommend to users to use a recent Java version.

[Don-vip]

Replying to johsin18:

Anyway, HiDPI is supported only from Java 9 really, isn't it? So that's what I care about.

Yes, with ​JEP 263.

You mean we have to stay compatible to Java 8?

Yes, until we switch the codebase to Java 11, the program must compile and run with Java 8.

But the users are free to install a later version, aren't they? For HiDPI, IMHO we should recommend to users to use a recent Java version.

You're totally right. Especially on macOS with Retina displays, we advise everyone to use the latest stable version of Java.

I'm descoping this ticket from the current milestone to release 20.03 early to address #18798, as we receive a lot of duplicates.

[johsin18]

#18694 has a patch that fixes also this problem.

[Klumbumbus]

Milestone renamed

[simon04]

@johsin18, should we close this ticket in favour of #18694?

[johsin18]

I suggest that we bring it the patch mentioned in #18694 first, then resolve this one.
BTW this one is targeted for 20.05, but #18694 only for 20.06.

[simon04]

Closed as duplicate of #18694.

[7rst1]

I still have this issue despite having updated to 16540. Is it certain that the patch for the issues with rendering in #18694 fixed this too? Is this only a patch for Windows, and so is there a separate issue for Linux users?

[johsin18]

Patch adding HiDPI-related information to the status report.

[johsin18]

The patch definitely helped in my case, for Windows 10. The faulty JDK code making this workaround necessary looks platform-independent to me. Still, I cannot rule out that things behave differently on Linux.

So to get this solved, please answer the following questions:

• Does the bug manifest right as before, or is it a bit better, or even worse? For which cursor type do you notice it?
  • Could you please send a screenshot of the haircross cursor and and node added when in this position, to showcase the offset? In case the screenshot does not show the cursor, consider making a physical picture.
• What Linux desktop do you use? KDE? Gnome? Something else? How do you configure the HiDPI scaling there?
• Do you have multiple screens? Are they all HiDPI? Which one is the "primary" screen?
  • I have attached a patch that extends the Status Report with some additional system information, which will help us nail down HiDPI issues in general.

[7rst1]

LinuxOffsetCursor

[7rst1]

The cursor offset looks exactly the same. Notice it with every cursor type. I use Java 14.

I use KDE Plasma with global scaling set to 175% and JOSM scaling set to 1,5. I have two screens, one being 4K and the other being 1080. The 4K one is primary.

[simon04]

In 16580/josm:

see #13173 - Add HiDPI information to status report (patch by johsin18, modified)

[johsin18]

I can reproduce the problem also on Windows 10. The JOSM scaling of 1.5 makes it fail. I will try to fix this case as well.

[simon04]

In 16584/josm:

see #13173 - PMD

[7rst1]

I guess you found out that the error is decimal scaling across all platform, so my status report probably isn't useful. Here it is anyways.

[simon04]

Related: #19360

[johsin18]

So I have attached a patch that should fix the hotspot problem with custom UI scale.

However, the cursor images with overlays are still not correct for a custom UI scale. IMHO the code needs to be refactored heavily before this could be fixed. The factors that influence the size and the scaling of cursor images lead to a combinatorial explosion, which makes it untestable.

• Hi-DPI scaling from the OS, via HiDPISupport.
• Toolkit.getBestCursorSize()
• gui.scale from the advanced preferences, via GuiSizesHelper
• iconsize.cursor from the advanced preferences, directly in ImageProvider

[simon04]

In 16764/josm:

see #13173 - Fix cursor hotspot for HiDPI (patch by johsin18, modified)

[7rst1]

Updated to 16769 and can confirm that the patch fixed it.

[simon04]

Thank you all!