GUI displays differing scaling for identical displays, between macOS and Windows, when both have equivalent UI-scaling enabled

[ELLIOTTCABLE]

At the moment, Cursr treats 'hiDPI' displays different on macOS vs Windows.

I have three identical displays; two are connected to a macOS box, and the third to a Windows machine. (There's also a fourth, small display connected to the macOS box.)

However, in the Cursr interface, the Windows-connected display appears gargantuan by comparison - compare the screenshot and photograph below, haha.

This issue is kinda the 'inverse' of #4 - that user wants to be able to force the displayed sizing of the monitors in the Cursr GUI to values matching their physical size, even though the resolution is different; whereas I want the Cursr GUI sizing to match their resolution, which it currently doesn't due to platform differences. (However, both issues could at least somewhat be addressed by offering the user the ability to simply resize the apparent size of their displays to whatever they want, I suppose ... although manual adjustment doesn't sound amazing to me.)

On both machines, there's GPU UI-scaling taking place (in both cases, 200%.) However, under macOS, this is the default and special action needs to be taken to change it - note that the macOS display preferences in the screenshot reports it as 1692×3008, and doesn't mention scaling at all; a user has to go out-of-their-way to reveal the "non-retina" displaymodes.

Meanwhile on Windows, to achieve similar window-chrome sizes, text spacing, etc, the Display settings are explicitly configured up from "Scale: 100%" to "Scale: 200%"; and the resolution drop-down displays 6016×3384, the actual physical resolution of the display.

This isn't a huge issue; manually configuring the transition-areas on each display-edge makes it a relative non-issue during daily use; but it's certainly confusing, and forces me to manually/painstakingly measure-out the configuration every time I have to change anything, instead of simply dragging the displays around to match their real-life arrangement and having the display-edges update accordingly. (=

(Finally, apologies if this is a duplicate; I could have sworn I reported this same issue sometime last year, but I can't find it now!)

Screenshots

macOS GUI:

Photo of actual setup:

Expected Behavior

If two identical displays, at the same pixel-density, and same scaling settings, on two different machines, show up in the Cursr GUI, I'd expect them to show up as the same size as one another.

Your Environment

• OS details:
  • macOS Sequoia 15.7.2 (24G325) on 64bit Intel X86 (MacPro7,1);
  • Windows 11 (25H2) on 64bit Intel 13th-gen Core i9
• Cursr Version: 1.7.3 (both)
• License: Pro (both)

[ragauskl]

UI scaling does not affect how Cursr renders the displays and how they are reported to Cursr.

At the moment Cursr renders the displays based on resolution only, for simplicity's sake. But more options on how to render the displays are already planned, just not a high priority. I would say there's some chance this will be released with 1.9 or 1.10

[ELLIOTTCABLE]

Well, my point here isn't so much that - if anything, a configurable option is "one more thing" to fiddle with.

I think an ideal fix would be to note, on macOS, displays that are in a hiDPI mode - unsure what language you're writing in, but in Swift/ObjC you'd want the NSScreen backingScaleFactor interface to determine whether the reporting resolution is accurate, or scaled. (Again, this is the inverse of Windows, where 'UI scaling' is not transparent to most of the APIs applications consume.)

With that fixed, at least this flavour of mis-sized display probably doesn't require user-configuration, I think?

[ragauskl]

Most of Cursr is written with Typescript and Electron, only the necessary native parts are written in a module using C++(with dash of ObjC++ to keep some files cleaner). In future Cursr will likely be rewritten with something else as current stack was selected for making the initial versions and based on existing knowledge but there are multiple other stacks which would be more performant and in some sense more neat than the current mess. However it may be long before that is possible but that's another topic.

I understand and agree that there shouldn't be too many things that have to be configured, but I'll need to do some research and have a good think on what may be best way to approach this, both from macOS perspective and from cross-platform consistency/simplicity perspective and other user needs.

As I spend least time working on macOS and only got into it for Cursr, I don't have a good idea what is expected/norm for all macOS users or from macOS developers perspectives so for these questions I always need to do extra research and/or consult with more macOS users or a macOS developer I know, that has been only using macOS and developing native apps on it for decades, to try and find a balance between what majority of macOS users will prefer or care about vs code simplicity as more 'exceptions' create more potential for bugs and require more maintenance down the road.

In terms of this issue, so far I’ve only had your report (and maybe a couple others but I can't find them right now) asking for something along these lines, so it hasn’t looked like a major widespread issue/annoyance, which makes it harder to prioritize so first there will be some higher priority tasks I need to clear before I can look into this and provide an update/continue discussion on potential solutions.

[ELLIOTTCABLE]

Ah, this isn't important to me at all, by the way; this definitely falls under "trying to help you out", not my personal needs. (Feel like I accidentally fell into an occasional role as your macOS-primary-user test-bench; I try to report issues I figure you probably haven't seen.)

Feel free to deprioritize this one; it's probably most relevant as an indicator that there's an underlying platform-parity component you're missing - I suspect that hiDPI-scaling handling-difference will bite you in much more important ways than the appearance of the GUI, at some point; maybe just something to keep in mind. o7

[ragauskl]

I will keep this in mind, thank you