Ability to turn off re-scaling when a window moves between monitors

[dweymouth]

Checklist

• I have searched the issue tracker for open issues that relate to the same feature, before opening a new one.
• This issue only relates to a single feature. I will open new issues for any other features.

Is your feature request related to a problem?

See the details here - dweymouth/supersonic#489 some users of Fyne apps find the auto-scaling when windows move between monitors jarring and would like to be able to disable it.

Is it possible to construct a solution with the existing API?

No response

Describe the solution you'd like to see.

An API or environment variable setting for disabling re-scaling of windows when moved between monitors. They should keep the same pixel size.

[andydotxyz]

They should keep the same pixel size.

To be progressed further this needs to be nailed down. What is the right pixel size - the one on the origin monitor, the one on the primary monitor or a simple 1:1 hard coded size?

[dweymouth]

Maybe @ccoenen (reported the issue in Supersonic) would like to weigh in?

[ccoenen]

I realize this is probably a preference thing, but personally I'm very used to windows changing their visible sizes across very different monitors (while at the same time keeping their physical-pixel size the same). I've been running two monitors since CRTs were standard. Personally, I would run this at "same pixel dimensions" even if the monitors were quite far apart in pixel-per-inch.

I'm not arguing that this must be the default or anything. But in the ticket I also mention that setting FYNE_SCALE=1.0 ENV-var doesn't change this behaviour for me.

In my current setup, both monitors have the same 1.0 scale factor set in GNOME. One is a 34" monitor with 3440x1440 pixels, one is a 14" monitor with 1920x1080 pixels. Yes they have different pixels per inch. No I do not mind. When I move the window across the dividing line, this is how that looks in a screen recording:

supersonic.mp4

It looks pretty similar to what Windows does when two monitors are set up with different scale-settings.

[andydotxyz]

while at the same time keeping their physical-pixel size the same

I am not certain we are talking about the same thing - the "pixel size" is in the hardware, we cannot keep it consistent across displays - we adapt to try and "fake" a consistency.

Can I check with this illustration to check we are talking same thing. A screen that is 1080p and a 4k, where both are the same size (27"). When you drag a window from one screen to the other should they:

1. be the same physical size
2. be 1/4 the area when dragged from 1080p to 4k?

I wonder if the window size and content scaling are being considered separately. Just ensuring we are consistent with terminology so we don't try to figure out a change on the wrong aspect.

[ccoenen]

I'm talking about the number of rendered pixels. I'm aware that these pixels will physically have different dimensions and that the window will therefore appear visually at different sizes.

Effectively: I want a 500x500 pixel thing to be 500x500 pixels, which would visually appear slightly larger on my slightly lower PPI screen and slightly smaller on my slightly higher PPI screen. It is fine that this is visually slightly different. I know that pretty much any window I drag across these two monitors will visually appear differently.

I don't want my 500x500 pixel window to be displayed at some odd number of pixels on one of them. I MOST OF ALL don't want it to make jumps in size the instant I drag it over the dividing line.

In short: For me, it should be 2.

Yes, I'm aware you probably put a lot of work in the automatic resizing. I just would prefer not to use it. I don't want you to throw it away or change anything dramatically, I just want to opt out.

[andydotxyz]

Thanks for the clarity - I know we are on the same page now. It's not something we can support in the general sense as most OS just don't work that way, but I suspect we can squeeze a Linux/Unix specific user override to turn off the scaling.

[ccoenen]

I am not sure we are on the same page, because what I'm asking is the default behaviour for literally every other software that I use? I have never encountered another program that does these kinds of jumps on any of my setups?

The most closely resembling thing would be windows with different scale factors on different monitors - there it performs a somewhat similar jump in size. But I'm not on windows AND my monitors are set to the same scale factor.

[andydotxyz]

But I'm not on windows AND my monitors are set to the same scale factor.

OK, so the "scale factor" is not a standard linux feature - but it is available to query as a standard on macOS and Windows, this is the main difference.
Fyne scaling is aiming to keep your apps consistent - like other operating systems do. This is not standard for linux apps as there is not a standard.

Depending on your desktop there will be different defaults - and apps from a different system will not necessarily respect the same defaults. Can you be more specific with details of what desktop system you are using, how you have set up these scaling factors, and which apps you are referring to which behave as expected?

[ccoenen]

This is a pretty boring Fedora 40 Install with Gnome 46.

Built in Laptop monitor

External Monitor

(I, personally, would say: scaling absolutely is a standard on GNOME, even if it's not a standard on linux as a whole. But this could probably be said for any given feature that's not part of the kernel or coreutils. Moving on.)

Other than these two screenshots and the video all the way up at the beginning, I really don't know what else to say. Fyne tries to do some magic. I don't want that magic. I want the most boring possible application window. One that is not aware of ppi, one that is not aware of screen size. One that just simply keeps to being a certain internal physical pixel size, regardless of the apparent size observable to the user.

In short: just like any other gui application that I'm currently looking at.

Here's what every software does on my (again: very boring) setup, this is represented by the default gnome calculator. And then it's compared to what fyne is doing, this is represented by the music player supersonic:

2024-10-27.10-29-00.fyne.scaling.mp4

To make sure there is no misunderstanding: this is a screen-recording, so it records the physical pixels. It is not a video I shot of my monitors.

[andydotxyz]

(I, personally, would say: scaling absolutely is a standard on GNOME, even if it's not a standard on linux as a whole. But this could probably be said for any given feature that's not part of the kernel or coreutils. Moving on.)

I think you're missing the FreeDesktop.org standards that we match for most of our desktop configuration options on Linux - scaling is not one.

Add to this the peculiar decision that GNOME made to only ever support int scaling (claiming that fractional is "impossible" for X11) whilst others have moved on and try to do float scaling to get exactly the output desired. We need to balance all of these factors, and it may result in having different behaviour for each window manager, but clearly that's something we would like to avoid if possible.

In short: just like any other gui application that I'm currently looking at.

As before is it possible to confirm what sorts of apps these are? Are they all GNOME apps? I would strongly suspect that things like "xterm" (no toolkit) and maybe even Qt based apps (respecting KDE settings) may not actually match this "any other app" summary in terms of scaling behaviour. Linux is fragmented and we need to understand all the different configurations and expectations this can lead to.

As above I do think that an "Turn off the auto-scaling" option would resolve it for you. But this is Linux specific and I don't think it should be default.

[ccoenen]

Yes, I do mean all other programs. Here's

• Firefox
• xterm
• gnome calculator (again)
• kdenlive (a KDE application)

2024-10-27.11-04-58.other.apps.mp4

I could go on. Here's a list of all the software I use on this machine, and really none of them do this jump in sizes on my system. https://alternativeto.net/lists/40087/what-s-on-my-2024-linux-laptop/

But this is Linux specific and I don't think it should be default.

as per my first post in this issue

I'm not arguing that this must be the default or anything. But in the dweymouth/supersonic#489 I also mention that setting FYNE_SCALE=1.0 ENV-var doesn't change this behaviour for me.

I'm not argueing for defaults. I would even have been fine with a rather hidden, advanced way of achieving this, like an ENV-var.

[ccoenen]

I will also add, that I used Debian for a couple of years and then Ubuntu for a couple of years before now using fedora for a couple of years (yes, all of them are effectively Gnome desktop environments). In over a decade of Linux on (my) computers, I cannot remember a single software that I used that had this behaviour. I use a lot of software, certainly not limited to gnome software.

[andydotxyz]

Yes, I do mean all other programs. Here's

Firefox
xterm
gnome calculator (again)
kdenlive (a KDE application)

Thanks it is good to have confirmation on the types of software.
I do not get the same results with Xterm, I guess I'll have to set up a new GNOME desktop and learn how they apply settings into the Xserver to assert scaling. For me the font on Xterm is half the size of other apps!

and really none of them do this jump in sizes on my system

Thanks. I was not meaning that they all jump in size - more that I was surprised that apps not coded for Gnome understand the monitor configuration that gnome asserts (because it's not an X11 configuration to my understanding).

I'm not argueing for defaults.

Thanks that is good to know as well, I think I misunderstood some of the more recent messages.
We can just go ahead with the simple override proposed earlier.

[dweymouth]

@andydotxyz Any suggestions for the naming of the setting or env var for this? FYNE_RESCALE_ENABLED=[0/false] perhaps?

[andydotxyz]

Well, the logic will need to be the reverse so it is that on by default.

I would avoid "rescale" because it isn't the rescaling that is disabled but the DPI detection or system scaling completely.

Someone combination of system scale or dpi in naming along with ignore or disable so that it's on unless disabled...

[dweymouth]

I thought it was the "rescaling" that was to be disabled - ie the scale detection would still be allowed to run at window creation, but once a window was created it would stick with that scale forever even when changing monitors?

[andydotxyz]

That seems peculiar - with those rules the a window will be a different size depending on which screen it was created on. If the OS creates it on the "wrong screen" then it may be unusable...

[dweymouth]

Maybe @ccoenen can weight in again? Would you be satisfied if the setting were to always use a 1:1 pixel scaling regardless of monitor DPI?

[ccoenen]

1:1 pixel scaling is what I - personally - would want. I don't want to impose any particular scaling, though. My personal problem is just the size jump that I tried to illustrate with the videos attached to the early posts, especially this one.

[dmarcoux]

It seems like I also have this issue or at the very least, it must be related.

I also have two monitors (laptop + external) with different sizes. Below, you can see how the scaling of the Supersonic window on my laptop's monitor is somehow wrong. This happens after transferring the Supersonic window from my external monitor to the laptop's monitor. I don't know why, but my mouse cursor appears to have an offset, so what is expected to happen when clicking on a song title (or something else) actually triggers something else. Here's an example where I try to double-click on the first song, but then it opens the album's cover, even though the mouse is on the first song.

[dweymouth]

This seems like a separate, but possibly related issue. @dmarcoux does this only happen if you drag the window from one monitor to the other? And is that title bar actually the top of the window there (ie it's cutting off the top of the page)? That might cause the mouse pointer to be off by the amount of vertical space that's being cut off, but I have no idea why it would cut off instead of rescaling the window content to fit within the frame. If you can reply with as many details about your system as possible too (OS, Desktop env., window manager, Supersonic version), that could help with debugging. @andydotxyz any ideas?

[andydotxyz]

A window with content larger than the desktop allows creates undefined behaviour.

[dweymouth]

A window with content larger than the desktop allows creates undefined behaviour.

The point is this is happening due to the Fyne runtime and not my code (because that list is allowed to shrink down to one row MinSize but it's not happening for some reason here). I'm guessing the user is dragging it across monitors and it's not properly triggering the rescale/redraw to layout the content to fit a smaller window if the OS is forcing a smaller window on us.

[andydotxyz]

Hmm, strange. Is that a tiling window manager? There is an issue somewhere in that stack whereby we don't always seem to register the resize correctly.

Will have to review once a few mysteries are eliminated with develop work.

[dmarcoux]

@dmarcoux does this only happen if you drag the window from one monitor to the other?

Yes, this happens only when moving the Supersonic window from my external monitor to my laptop monitor.

And is that title bar actually the top of the window there (ie it's cutting off the top of the page)?

The whole window is cut off, this includes the titlebar.

I am using Supersonic 0.13.2 on NixOS 24.11 with the i3 tiling window manager. This is the first time I experience this issue, my browser and other applications don't have this. Both monitors have a resolution of 1920x1080, but with a different sizing (from xrandr: 344mm x 194mm and 531mm x 298mm).

[dweymouth]

@ccoenen Added a new env var for next Fyne release (and I'll pull it early into Supersonic if I do a release before the next Fyne release). @dmarcoux your issue is separate and will still need to be looked into

[andydotxyz]

They may be different issues, but the subject line is addressed so this should be closed and if the other item is not resolved then a new issue opened.

[ccoenen]

Thanks everyone! I'll give it a try as soon as possible!