Custom cursors and high dpi (Windows and MacOS testers needed)

[vocx]

...This PR is getting larger and larger. I'm afraid it's getting harder to review. Would you suggest I create a separate PR or continue improvements in this one?...

I do suggest you keep the pull requests small, with less than 10 commits each, if possible. And I would also avoid touching a lot of files at the same time, although this is unavoidable some times.

There is no way to speed up review and merging. Maybe if you bribe with millions of dollars one of the people with merge privileges you can expedite this. But otherwise, that's just how it is. Contribute as much as possible. It won't be a waste, you just need to be patient.

[davidhbrown]

Hello; sorry to jump in, but it sounds like you are working on the Sketcher cursors that started giving me trouble a month or two ago (in the 0.19 releases).

I am experiencing an issue with a HiDPI screen in Windows 10 (Version 2004, OS Build 19041.487) and the Sketcher cursor crosshairs being misaligned from their hot spot. The hotspot is below and to the right of the crosshair. The problem does not exist if I set my screen to 100% magnification, but its recommended is 150% where it shows the problem. I also tried 200% in case it was a fractional multiplier issue but the problem is at 200%, too.

While I haven't yet set up the build tools for FreeCAD, I probably could if I could be of help in testing (noting the topic title).

This version works okay:

OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.21769 (Git)
Build type: Release
Branch: master
Hash: 801bfe4ba5f0910e9b2885917c521ab7fd8e9020
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)

This version and all later versions exhibit the offset:

OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.22270 (Git)
Build type: Release
Branch: master
Hash: 45d28c2367f5714cf5463b3373979c2a6f2779bf
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)

The simplest steps to reproduce are to create a new document, select the Sketcher workbench, create a new sketch in any plane. Select the line segment tool. Click anywhere away from the axes and begin to drag, noticing that the line segment appears below and to the right of the crosshairs. If you have automatic constraints enabled, finish the first line segment and try to connect another one... you will see again that the hotspot is below and to the right of the crosshairs.

Thank you very much; please let me know if I can assist or if I should start a bugtracker issue... or if I'm wrong

David

[vocx]

This version and all later versions exhibit the offset:

Version: 0.19.22270 (Git)

Pull request #3712
Version 0.19.22268 is git commit 7a0aec12 by Vanuan (big change).
Version 0.19.22269 is git commit b53326b3 by Vanuan (only Draft).
Version 0.19.22270 is git commit 45d28c23 by Werner.

Is 0.19.22269 working fine? Can you test? Then the additional code added by Werner caused the shift.

ping

[vanuan]

Ok. I think I can see what you mean:

Screenshot from 2020-09-20 22-31-31.png (9.81 KiB) Viewed 1887 times

So the hot point appears to be 1 pixel less than the actual center.

Here we can see that the coordinates of the center of cross-hair are "16, 16" for a an icon of size 64x64:

Screenshot from 2020-09-20 22-42-55.png (52.08 KiB) Viewed 1887 times

The coordinates of the hot point for the old were "7,7" for an icon of size 32x32:

Screenshot from 2020-09-20 23-20-47.png (31.58 KiB) Viewed 1887 times

Screenshot from 2020-09-20 23-21-17.png (25.11 KiB) Viewed 1887 times

So yeah, when converting from XPM to SVG we missed the fact that XPM's crosshair was centered in 7,7 (equivalent of 14,14) rather than 8,8 (equivalent of 16,16).

So now we can either change all the SVGs or change the 7,7 to 8,8. I think the latter would be better. So here it is:
https://github.com/FreeCAD/FreeCAD/pull/3883

[davidhbrown]

This version and all later versions exhibit the offset:

Version: 0.19.22270 (Git)

Pull request #3712
Version 0.19.22268 is git commit 7a0aec12 by Vanuan (big change).
Version 0.19.22269 is git commit b53326b3 by Vanuan (only Draft).
Version 0.19.22270 is git commit 45d28c23 by Werner.

Is 0.19.22269 working fine? Can you test? Then the additional code added by Werner caused the shift.

ping

I didn't mean to implicate 0.19.22270 as the source of the problem; it is just the version I happened to have downloaded in which I first observed the issue. I do not have a copy of 0.19.22269 myself; it looks like I hadn't updated for about 2mo and the next earlier version I have is 0.19.21769 which was okay, but of course there was a lot in-between.

[vocx]

...
I didn't mean to implicate 0.19.22270 as the source of the problem; it is just the version I happened to have downloaded in which I first observed the issue...

Is this true?! Then this is the greatest coincidence ever!

Because in exactly these commits the changes to the cursors were made, and as you see, vanuan just submitted the corresponding fix.

[davidhbrown]

...
I didn't mean to implicate 0.19.22270 as the source of the problem; it is just the version I happened to have downloaded in which I first observed the issue...

Is this true?! Then this is the greatest coincidence ever!

Because in exactly these commits the changes to the cursors were made, and as you see, vanuan just submitted the corresponding fix.

Yeah, that coincidence is making me a little nervous because it's not like much good has been happening in 2020 (at least not compared to other years)! I just cloned the repo and am working on setting up the build chain so I might try the fix myself.

I'm also puzzled because it looks like vanuan's Screenshot from 2020-09-20 22-31-31.png shows the hotspot northwest of the crosshairs where I'm seeing it southeast, in-between the white crosshairs and the varying red icon for each tool. Cursors disappear during screen captures, so here's a photograph showing a vertex highlighted in yellow (also the automatic coincident constraint icon appears) but the crosshairs are above and to the left. This is also a link to https://imgur.com/a/jjxQxqK which has a higher resolution version if you want:

[vanuan]

I'm also puzzled because it looks like vanuan's Screenshot from 2020-09-20 22-31-31.png shows the hotspot northwest of the crosshairs where I'm seeing it southeast, in-between the white crosshairs and the varying red icon for each tool.

Hm. It's puzzling. It appears the hot spot is precisely at the center of the cursor. The cursor includes the white crosshair and the red "create line" tail. Can you confirm?

Unfortunately, I don't have Windows to investigate.

[davidhbrown]

[...] It appears the hot spot is precisely at the center of the cursor. The cursor includes the white crosshair and the red "create line" tail. Can you confirm?

It is approximately at the center of the cursor, but I don't think precisely. I believe that appearance was a contingent on the system scaling percentage -- in that case 150% -- and perhaps the specific cursor. I also tried with the system scaling percentage at 350% (good thing I have a 4k monitor!) and the hotspot was slightly to the right of the "create line" tail and almost to the bottom of it. With the system scaling at 100%, the hotspot is directly in the middle of the crosshairs.

\begin{wildconjecture}
I haven't looked at the code yet (trying to figure out how to get CMake to use the right compiler, I think, but this isn't the forum for that), but it looks almost as if whatever scaling of the shift to move the hotspot from (0,0) at the top left over to (7,7) or (8,8) for the center of the crosshair is being done twice. Like maybe there's some old special-case Windows code from QT4 that isn't needed any more with QT5. But I'm completely guessing at that.
\end{wildconjecture}

I could try to put together a series of images showing the cursor and hotspot at a variety of scalings if you think that might be helpful.

[vanuan]

It is approximately at the center of the cursor, but I don't think precisely. I believe that appearance was a contingent on the system scaling percentage -- in that case 150% -- and perhaps the specific cursor. I also tried with the system scaling percentage at 350% (good thing I have a 4k monitor!) and the hotspot was slightly to the right of the "create line" tail and almost to the bottom of it. With the system scaling at 100%, the hotspot is directly in the middle of the crosshairs.

Hm. Interesting. So the larger the dpi ratio, the larger are the hot spot coordinates. Well, they should be. But it appears to be an overshot by a factor.

it looks almost as if whatever scaling of the shift to move the hotspot from (0,0) at the top left over to (7,7) or (8,8) for the center of the crosshair is being done twice. Like maybe there's some old special-case Windows code from QT4 that isn't needed any more with QT5. But I'm completely guessing at that.

Something like that

I could try to put together a series of images showing the cursor and hotspot at a variety of scalings if you think that might be helpful.

Well, that would be helpful to test my theory if I come up with one
Let me think...

So one theory would be that on Windows the hotX and hotY are always specified in relation to a cursor of size 32x32. So those don't have to be multiplied.

That would mean that when 7 is multipled by a dpi ratio of 400% it would be at the coordinates 28,28 which would be almost at the bottom right of the cursor of size 32x32. Around the center it would be when it's 14,14, that is at scaling ration of 200%.

I don't know what to make of this. Isn't Qt supposed to be crossplatform? Or maybe the cursor of size larger than 32x32 is not supported on Windows?

https://doc.qt.io/qt-5/qcursor.html#QCursor-3

Valid cursor sizes depend on the display hardware (or the underlying window system). We recommend using 32 x 32 cursors, because this size is supported on all platforms. Some platforms also support 16 x 16, 48 x 48, and 64 x 64 cursors.

There's another, your theory. Is that the scaling is done twice. That is 7 is multiplied by dpi ration squared. That means for 400% it would be 7*4*4 = 122. The cursor size at 400% is 32*4 = 128. For cursor of size 200% it's 7*2*2 = 28 for size 64 (at the center). For cursor of size 350% it's 7*3.5*3.5 = 85 for size 112.

Well, it seems both theories give the same results. But they can't confirm the reason for a difference between Windows and Linux