Ensure Canvas Matches Actual Window Size #5797
Conversation
andydotxyz
left a comment
andydotxyz
left a comment
There was a problem hiding this comment.
Thanks so much for working on these fixes - great to have the underlying issues figured out.
As discussed on the issue it looks like it might be good to split between the resize and the re-scale/move issues to two PRs.
One overall PR comment is that comments should only be used where the intent of the code cannot be communicated directly. i.e. don't duplicate what is written in code.
andydotxyz
left a comment
andydotxyz
left a comment
There was a problem hiding this comment.
Just a few more comments as I was catching up on PRs
When a Fyne application window is opened in a tiled window manager or constrained by other window management, the canvas size could become out of sync with the actual window dimensions, causing widgets to be positioned incorrectly making the window to unresponsive to input. This occurred because the canvas coordinate system didn't match the window's actual size, resulting in input events being misaligned with visual elements. The issue was in RescaleContext(), which assumed it could resize the window to match the canvas size. However, when the window size is constrained (by a tiling window manager, during scale changes, or other scenarios), this approach fails. Use its actual dimensions to recalculate the canvas size. Add window size verification to the canvas Resize() function. When the canvas is resized, the code now checks if the actual window size differs from what would be expected for the requested canvas size. If a mismatch is detected (indicating the window manager has constrained the size), the canvas size is recalculated based on the actual window dimensions.
cwarden
changed the title
|
Please try to avoid force-pushing after reviews have start. It means we have to review from scratch on every change. |
|
The code looks good, but I am away from my multi-monitor setup for another week so cannot really test this. If anyone else is able to verify it that would be great. |
Sorry, that's actually one of my own guidelines. I thought it was worth breaking based on the history of this PR, but I should have checked with you first. |
cool cool. When it feels like a squash or a re-base is better you can note it on the PR and the person landing it can do that action after the reviews etc all complete :). |
|
It does make things a lot smoother - but it doesn't remove flicker all together so let's not close out the other issue. This change seems to essentially stop the window resizing when moving from one display to another (previously it would adjust so when the scale changes the window size adapts to make the same amount of content visible). This is a complex area and I think perhaps if the trade-off is required then it's a reasonable one - let the window be whatever size the desktop thinks it should be and just adjust the content so scale works as expected. Thoughts? |
| newWidth, newHeight := w.screenSize(size) | ||
| w.viewport.SetSize(newWidth, newHeight) | ||
| // When scale changes (e.g., moving between monitors), we need to recalculate | ||
| // the canvas size based on the current window size, not the other way around |
There was a problem hiding this comment.
This seems like the source of the change in behavior - with previous setup it was correct to adjust the window size based on the content and scale so that when moving when scale changes the window changed too (worked on all except gnome moving from a low scale to high scale monitor - desktop would not allow the window to shrink).
I wonder if there is a way to fix tiling whilst maintaining the old behavior?
I don't really know why tiling breaks in this code so I'm not sure if there is a happy medium.
There was a problem hiding this comment.
Isn't the issue that fyne can't control the window size in every environment? But it can control the canvas size so when it doesn't get the window size it wants, it needs to adjust the canvas size.
There was a problem hiding this comment.
That would make sense.
So instead of trying to control it with this PR it doesn't try any more? Can we somehow attempt to resize and fallback if it doesn't work?
There was a problem hiding this comment.
I don't regularly work with non-tiled windows, but the automatic resizing feels awkward to me.
The behavior with the changes in this branch feel more intuitive to me.
There was a problem hiding this comment.
I would want to test this PR again but I do agree that using this PR felt more natural when I moved the window between screens.
There was a problem hiding this comment.
I think we need to compare how other apps behave when moving them between windows. This is a GTK4 app:
Screencast.From.2025-09-06.08-20-01.webm
This is Fyne before this change (jumps a bit in size also):
Screencast.From.2025-09-06.08-20-38.webm
This is with this PR:
Screencast.From.2025-09-06.08-23-05.webm
With this, it actually behaves more like the other apps on my system and like what I would expect. The scaling and/or window size seems to potentially be a bit smaller than before though, I think?
There was a problem hiding this comment.
I'm not sure that comparing to GTK+ is a good idea - they have declared that fractional scaling on X11 is not possible and rely on gnome desktop hinting instead of DPI detection.
Not apples and Oranges.
If you compare with how apps work on Windows or macOS you will see the scale changes and the size changes so that the UI is a consistent size unless user specifies other default for the monitors.
There was a problem hiding this comment.
If you want the GTK version then turn off DPI detection completely rather than removing it from the codebase.
There was a problem hiding this comment.
I'm not sure that comparing to GTK+ is a good idea - they have declared that fractional scaling on X11 is not possible and rely on gnome desktop hinting instead of DPI detection.
Not apples and Oranges.
What does their opinion on X11 and fractional scaling have to do with it? I am using Wayland and have 125% fractional scaling enabled on the right monitor. It works perfectly. The behaviour of this app seems more sane after this change than before.
There was a problem hiding this comment.
I'm sorry - are you doing all of this testing with pure-wayland compiled Fyne? I did not realise that was the case. If so it is a different code path and I will have to re-analyse as the wayland scale handling is not the same as X11.
|
I think the race conditions in the CI are actually caused by this change btw - I can't see at a glance why |
4 participants
[see /issues/5801 for context]
When a Fyne application window is opened in a tiled window manager or
constrained by other window management, the canvas size could become out
of sync with the actual window dimensions, causing widgets to be
positioned incorrectly making the window to unresponsive to input. This
occurred because the canvas coordinate system didn't match the window's
actual size, resulting in input events being misaligned with visual
elements.
The issue was in RescaleContext(), which assumed it could resize the window
to match the canvas size. However, when the window size is constrained
(by a tiling window manager, during scale changes, or other scenarios),
this approach fails. Use its actual dimensions to recalculate the canvas size.
Add window size verification to the canvas Resize() function. When the
canvas is resized, the code now checks if the actual window size differs
from what would be expected for the requested canvas size. If a mismatch
is detected (indicating the window manager has constrained the size),
the canvas size is recalculated based on the actual window dimensions.