Mouse Curor Position is "off" on external monitors

[sygibson]

I recently upgraded from 5.0.1 (IIRC) to 5.6.0, and then the latest 5.6.1-2 beta.


With my recent upgrade, I'm experiencing a "weird anomaly" ... The mouse cursor position is "off" by a bit. Where I have the mouse positioned on the screen is below and to the left of the actual point that is being referenced on the charts.


This means "zoom to cursor" actually zooms to a point above and right of the cursor ... and I have yet to be able to find the right "offset" in various zoom levels to be able to click on waypoints or track lines.


This only occurs when I move the OpenCPN window from the base laptop to an external monitor ... which is how I run the system onboard.


I am running the MacOS version, on a Mac Book Pro with external Dell monitors via the Lightning to HDMI connection.


Has anyone else observed this behavior? I did search through the forums, but was unable to find any other references to this.

[sygibson]

For reference, the "red x" in the posted image is roughly the offset from the marked "cursor position".


This problem exhibits on 5.6.0, 5.6.1-2 (beta), and 5.6.1-4 (beta/RC).

[bcn]

Why this is an issue? Thinking about a practical scenario?

[sygibson]

I use an external monitor to the main laptop for navigation. I have an external Monitor in the pilothouse and an external monitor on the flybridge connected to the laptop via HDMI cables and USB cables for keyboard/mouse.



This means that I can not click on any Waypoints or Routes.


Zooming in and out behaves "erratically" - as the mouse cursor position is offset from "reality" - and as such, the charts zoom to a point my cursor is not pointing at - see the "offset" different that I roughly determined in the posted image.


It essentially makes OpenCPN unusable for interactive use on my external monitor setup. This only occurs in this Application - no other application or software behaves this way.

Originally Posted by bcn

Why this is an issue? Thinking about a practical scenario?

[nohal]

I am afraid there is little we can do about this at the moment due to the limitations in multi monitor support in wxWidgets.

The issue is (I suppose OP's MacBook has a Retina display) that the Retina display's physical resolution is double the size of the screen in "device independent pixels" and as soon as the scale 2.0 is acquired from the primary retina display it keeps being applied to the coordinates even when the window gets moved to the external display having scale 1.0.

To make it worse this stuff works completely differently on other platforms.

There will probably be some solution to it, but given the percentage of users with this scenario I think I'm also not immediately running to the nearest store to buy an external monitor and another PC notebook with HiDPI screen to test Linux and Windows and start working on it.

But of course we will have to do something about it.

[sygibson]

Thank you for the reply - it definitely helps to understand some of the underlying issues causing the problem. Doesn't make it work ... but ... :-)



Are there any recommendations that might help? For example - setting the retina display and the external monitors to the same pixel resolution size ... or something to that effect?

Again - thank you - I do greatly appreciate the reply!

Originally Posted by nohal

The issue is (I suppose OP's MacBook has a Retina display) that the Retina display's physical resolution is double the size of the screen in "device independent pixels" and as soon as the scale 2.0 is acquired from the primary retina display it keeps being applied to the coordinates even when the window gets moved to the external display having scale 1.0.

[nohal]

There really is not much you can do at he moment but not mixing HiDPI and "normal" displays in the same system. One way to achieve that, with it's own set of issues, is to use remote desktop connection instead of external monitors.
There are a lot of changes in this area landing in wxWidgets right now and 3.2 should hopefully be released in June, so there is chance the next "big" OpenCPN release at the end of 2022/beginning of 2023 will have some relevant improvements for your setup. Until then we have to live with the current limitations.

[HeywoodJ]

There is a piece of software out there, BetterDummy that is intended to help Mac users with exactly this problem. Have not tried it with O, but it does help with some issues on a graphic design MacBook Pro system.

There's a bit of an article here that might shed a bit more light than the GitHub page. The article talks about M1, but the software should also run on Intel.