Cursor size on multi-monitor setup when creating relationships

[steverumsby]

Version of Archi

4.9.1

Archi Plug-ins

Operating System

Windows 10

Actual Behaviour

I have an MS Surface with two external 1080p monitors (22", so much lower dpi than the Surface monitor). On the Surface display everything appears to be fine.

When the archi window is on one of the external monitors, and I try to create a relation between two elements, while dragging the mouse the cursor is way too big.

This is the appearance on the Surface monitor:

This is the appearance on the external 1080p monitor (apologies for the dodgy colour balance!):

I haven't noticed this behaviour in any other context. As far as I have noticed, everything else looks correct on the external monitors.

This did not happen with 4.8.1. The cursors were still different on the two screens, but not oversized on the external monitor.

[Phillipus]

We changed the way cursors are created in 4.9 so as to use double-sized if scaling is 200% DPI on the target device. This works if there is only one monitor. It seems that it is picking up the high DPI one cursor first and using that for all monitors. Is this also happening with the Magic Connector cursor?

[steverumsby]

Yes, the magic cursor does the same thing. It does indeed look like it is using high DPI cursor from the Surface screen for the external monitors also. But this doesn't happen when you drag an element from the palette onto the diagram. That's almost the same cursor - an arrow with a + - but that is sized correctly.

[Phillipus]

But this doesn't happen when you drag an element from the palette onto the diagram. That's almost the same cursor - an arrow with a + - but that is sized correctly.

That's the system cursor so it's not affected.

This is tricky to solve. In Eclipse, any images and icons that have a @2x in their name will be used on HI-DPI devices. The cursors in question are created once so if the first monitor found is a HI DPI device then that's what is used.

I might make an experimental build where cursors are dynamically created. But it won't solve the problem if the Archi window is dragged from one monitor to another and the cursor has already been created.

I shall investigate...

[steverumsby]

Of course, dragging windows from one monitor to another is something I do all the time :-(

The 4.8 behaviour was not perfect, now that I look at it closely, but it was definitely better.

Happy to test experimental builds if that's helpful.

[Phillipus]

I'm sure it can be solved. I'll ping you with an experimental build soonish.

[Phillipus]

But it won't solve the problem if the Archi window is dragged from one monitor to another and the cursor has already been created.

Actually that won't affect anything.

[steverumsby]

It looks like it is always using the DPI from what Windows calls its "main display". If I tell Windows to use one of the external monitors as my main display, then I get a normal sized cursor on those monitors and a teeny, tiny one on the surface display.

This happens regardless of where the initial archi window opens.

[Phillipus]

Yes, that's how it works.

The old cursor in Archi 4.8.1 uses one 32x32 cursor in all cases. Can you check if the 4.8.1 cursor looks teeny, tiny when you do the same procedure?

[steverumsby]

With 4.8.1, the cursor size changes with my "main display" (bigger on the low DPI external monitor - smaller on the high DPI Surface monitor), but if I move a window after archi has started the cursor doesn't really change size like it does with 4.9.1. Could there be some Windows scaling going on? These are my display settings for the Surface display:

I have just noticed, though, that the above is all true of the standard relationship connector in the palette, but the magic connector does still resize when I move a window between displays. It is bigger on the low DPI monitors and smaller on the high DPI Surface screen. In 4.8.1.

[Phillipus]

Strange, The 4.8.1 cursor is created once with a 32x32 gif image at 100% scaling, so it should appear to be too small on the hi-dpi screen.

[Phillipus]

Having looked at the Eclipse code more I can't see that this can be solved. It seems that the scaling factor (either 100% or 200%) is determined once at startup for the primary monitor.

So if the primary monitor is hi-dpi the cursor uses a 64x64 image, otherwise 32x32. So it will be either too big or too small on the other monitor.

You could try this build where I create the cursor each time it is used but because of the reasons above I don't think it will make any difference:

https://www.archimatetool.com/downloads/beta/Archi-Win64-4.9.1-test1.zip

[steverumsby]

You're right - it makes no difference. Behaviour is exactly the same. My recollection is that this worked better in 4.8.1 - I'll try and do some comparisons to see exactly what it did. Is it possible to go back to the 4.8.1 method?

[Phillipus]

Is it possible to go back to the 4.8.1 method?

That still has problems. That method uses a 32x32 image for the cursor at all scales. This means that the cursor is too small on hi-dpi (200%).

[steverumsby]

I understand, but as I said, I didn't really notice that. Could Windows scaling have been kicking in to make it bigger on the high DPI display? I'll run both side by side this afternoon and compare behaviours.

[steverumsby]

It turns out my memory was slightly faulty. Of course you are right - 4.8.1 produced the same effect when moving a window from the high DPI display to a low DPI display - the cursor grew in size. But it was starting from a smaller cursor in the first place - too small, perhaps for the Surface display? But I guess the combination of too small on high-DPI/normal on low-DPI is visually better than normal on high-DPI/too large on low-DPI? At least to my eyes. Certainly it never occurred to me as a problem with 4.8.1 but was "obviously wrong" in 4.9.1.

If there is indeed no way to fix it "properly" - generating the cursor on demand, appropriately sized for the display it is visible on - then could it be made an option? The current behaviour as default, but the option of the small or large cursor if you prefer?

Cursor size: Auto [x] Small [ ] Large [ ]

I would certainly go back to the 4.8.1 behaviour if I had the opportunity.

[Phillipus]

The cursor in 4.9 is exactly the same as the cursor before. It's a 32x32 image. The only difference is there's also a 64x64 version of the cursor for 200% display scale. To get the 4.8.1 behaviour all you have to do is set the 100% scaled monitor as the primary device.

[steverumsby]

Sure, but there are other implications of setting the primary device that mean, for me at least, I don't really want to change it. If that's the only solution then I'll live with it the overly large cursor on the low-DPI screens. It doesn't affect functionality after all. It just looks odd. It would be nicer to have the choice, but you've probably got more important things to spend your time on!

[jbsarrodie]

@steverumsby Have you tried forcing DPI setting for Archi so that it uses the same settings whatever global DPI setting you have? Seems possible, see https://www.windowscentral.com/how-change-high-dpi-settings-classic-apps-windows-10-april-2018-update

[steverumsby]

Thanks for the pointer. I'd forgotten those settings existed! With a bit of playing, I seem to be able to get it to the point where I have small on high-DPI/normal on low-DPI combination rather than normal/large, which works OK for me. For the record, the High DPI settings that work for me are:

If there's no way to fix this in the application, and it sounds like there isn't, then I guess this is a good enough solution. Or alternatively I could upgrade my monitors to 4k so everything was high-DPI :-)

[Phillipus]

You could also rename the image files that are used for the cursors in this folder:

Archi4\plugins\com.archimatetool.editor_4.9.1.202110260902\img\

1. Delete add-cursor@2x.png
2. Copy add-cursor.png and rename it to add-cursor@2x.png

Do similar for add-connection-cursor.png, addnot-connection-cursor.png and addnot-cursor.png.

[Phillipus]

Let's close this one as there are some options to manage this.