Repository navigation
Fix X11 default window size being scaled twice on HiDPI screens - #22255
Conversation
The default size is computed in pixels while RenderScaling is still 1, so UpdateScaling() later treated it as DIPs and multiplied it by the monitor scaling. Initialize the scaling from the same monitor. Fixes #22254 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
grokys
added
bug
area-x11
backport-candidate-12.1.x
There was a problem hiding this comment.
🟢 Approval recommended
No unresolved review issues were identified.
Pull request overview
Fixes X11 HiDPI default window sizing being scaled twice.
Changes:
- Initializes scaling from the selected monitor.
- Prevents duplicate scaling of default dimensions.
File summaries
| File | Description |
|---|---|
src/Avalonia.X11/X11Window.cs |
Initializes scaling consistently with the monitor used for default sizing. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
You can test this PR using the following package version. |
|
|
||
| // The default size is in pixels, so initialize the scaling to match the monitor. | ||
| // Otherwise UpdateScaling() would treat the pixel size as DIPs and scale it again. | ||
| RenderScaling = monitor.Scaling; |
There was a problem hiding this comment.
Looking at the usages of Scaling/_scalingOverride, the following seemed suspicious:
With the changes, it means we're now having Scaling == 1.5 but _scalingOverride == 1.0 when an embed is created (OnHandleCreated is called from the constructor). I wasn't sure if these could cause issues (the existing embed doesn't seem to display correctly in the ControlCatalog for me), so I asked Claude.
According to it, this causes the next configure event to call UpdateScaling, where 1.0 != 1.5, causing an incorrect resize of the embed.
There was a problem hiding this comment.
Good point - embedding indeed wasn't considered!
There was a problem hiding this comment.
Fixed and tested with the XEmbedSample. The ControlCatalog Native Embed page doesn't use XEmbed so that's the wrong sample to test with.
I have no idea whether the clanker-added comments are over the top here or not... Feel free to trim them if you think they're overkill (I find this part of the code hard to follow, so any comment is useful to me).
There was a problem hiding this comment.
Fixed and tested with the XEmbedSample.
My bad, I completely forgot about this one, despite its obvious name!
I have no idea whether the clanker-added comments are over the top here or not...
For once, I think they're fine. I agree that the X11WindowMode nested class modifying its parent window's fields isn't the easiest to follow.
XEmbedClientWindowMode sets a scaling override of 1 in OnHandleCreated, which runs after RenderScaling was initialized from the monitor. The mismatch caused the next UpdateScaling() to trigger a spurious DPI resize of the embedded window on HiDPI screens. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
You can test this PR using the following package version. |
…oniaUI#22255) * Fix X11 default window size being scaled twice on HiDPI screens The default size is computed in pixels while RenderScaling is still 1, so UpdateScaling() later treated it as DIPs and multiplied it by the monitor scaling. Initialize the scaling from the same monitor. Fixes AvaloniaUI#22254 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Respect XEmbed scaling override when initializing X11 window scaling XEmbedClientWindowMode sets a scaling override of 1 in OnHandleCreated, which runs after RenderScaling was initialized from the monitor. The mismatch caused the next UpdateScaling() to trigger a spurious DPI resize of the embedded window on HiDPI screens. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
MrJul
added
backported-12.1.x
and removed
backport-candidate-12.1.x
…oniaUI#22255) * Fix X11 default window size being scaled twice on HiDPI screens The default size is computed in pixels while RenderScaling is still 1, so UpdateScaling() later treated it as DIPs and multiplied it by the monitor scaling. Initialize the scaling from the same monitor. Fixes AvaloniaUI#22254 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Respect XEmbed scaling override when initializing X11 window scaling XEmbedClientWindowMode sets a scaling override of 1 in OnHandleCreated, which runs after RenderScaling was initialized from the monitor. The mismatch caused the next UpdateScaling() to trigger a spurious DPI resize of the embedded window on HiDPI screens. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
What does the pull request do?
Fixes the default window size on X11 being scaled twice on HiDPI screens.
What is the current behavior?
A
Windowwith noWidth/Heighton a 3840×2160 monitor at 1.5× scaling (working area 3840×2133) opens at 4320×2239 px instead of 2880×1493. It's larger than the screen, so the WM may auto-maximize it, and restoring it gives the oversized window.What is the updated/expected behavior with this PR?
The window opens at 75% × 70% of the working area in pixels (2880×1493 in the example above).
How was the solution implemented (if it's not obvious)?
X11Window's constructor computes the default size in pixels whileRenderScalingis still1, soClientSizereports it as DIPs.UpdateScaling()then picks up the real scaling and callsResize(oldScaledSize), scaling it again. The fix initializesRenderScalingfrom the same monitor used to compute the default size, soUpdateScaling()sees no change.Tested with the same change applied to 12.1.2, on Fedora/XFCE (X11) at 1.5× scaling.
Checklist
Fixed issues
Fixes #22254
🤖 Generated with Claude Code