Bug Report: Snap Assistant renders at incorrect size on high-DPI display without fractional scaling

[droidleader]

Summary

The Snap Assistant shelf (the layout picker that drops from the top center of the screen when dragging a window) renders at a physically oversized scale on a 4K display running at 100% GNOME scaling. The UI element occupies a disproportionately large portion of the screen compared to all other UI elements.

Environment

• OS: Fedora 44 (Wayland)
• GNOME Shell version: (please confirm with gnome-shell --version)
• Tiling Shell version: v17.3 (latest)
• Display: Wacom Cintiq Pro 24 — 3840×2160, 60Hz, Scale: 150% (fractional scaling via Wayland)
• Multi-monitor setup: Yes — 3 monitors (Wacom Tech 24", Dell Inc. 25", ASUSTek COMPUTER INC 27")
• Session type: Wayland
• GPU: NVIDIA RTX 4070 Ti 16GB

Steps to Reproduce

1. Run a multi-monitor setup with a 4K display set to 100% scale (no fractional scaling)
2. Grab any window and begin dragging it
3. Move the window toward the top center of the screen to trigger the Snap Assistant shelf

Expected Behaviour

The Snap Assistant shelf should render at a consistent, proportionate size relative to other GNOME UI elements (top bar, window decorations, etc.), correctly accounting for the monitor's fractional scale factor.

Actual Behaviour

The Snap Assistant shelf renders extremely large — occupying roughly the full width of the screen and a significant vertical portion. Other GNOME UI elements (panel, windows, settings dialogs) render at a normal, readable size at 150% scale.

The shelf appears to be over-scaling — likely applying the 150% scale factor incorrectly (e.g. doubling it, or applying it on top of an already-scaled value), resulting in a UI element that is far larger than intended.

This issue did not occur on Ubuntu with the same hardware and Wayland configuration, suggesting it may be specific to how Fedora's Wayland compositor exposes the fractional scaling API, or a difference in how GNOME handles 150% fractional scale between distributions.

Screenshots

See attached screenshots showing:

• The oversized Snap Assistant shelf appearing at the top of the screen (screencast frames at 00:00:03, 00:00:09, 00:00:17)
• The display settings confirming 3840×2160 at 100% scale and 60Hz (screenshot at 09:19:48)

Additional Notes

• The layout picker popup accessed via the panel indicator renders at a correct, normal size — this is unaffected
• The issue is isolated to the dragging-triggered Snap Assistant shelf specifically
• Potential root cause: the shelf may be applying the Wayland fractional scale factor twice, or computing its size in physical pixels and then scaling again — resulting in a shelf that is ~2.25× too large (150% × 150%)
• Worth testing at 100% and 200% scale to determine if the issue is specific to non-integer fractional values like 150%

[domferr]

Hi, first of all thank you for reaching out!

renders at a physically oversized scale on a 4K display running at 100% GNOME scaling

I also have a 4K display and I have 200% scaling without fractional scaling. And I have Ubuntu. To me it renders correctly, so I can clearly see that there are so many different factors here that might be the root cause.

---

Let me tell you this: believe me or not but in 2026, when fractional scaling is disabled, GNOME applies the primary monitor scaling to all the monitors you have... With Tiling Shell I had to make an internal scaling engine, so Tiling Shell computes the sizes per monitor instead of using the primary monitor scale. This engine is disabled when fractional scaling setting is active, since that setting is solving the same issue. Tiling shell defines if fractional scaling is active by looking at the conf org.gnome.mutter.experimental-features and checking if that array contains the string scale-monitor-framebuffer or x11-randr-fractional-scaling.

Could you give a look at that conf please? Maybe Fedora has a different configuration!

[droidleader]

Thanks for the reply and the explanation of the internal scaling engine — that makes sense as a likely root cause to investigate.

I ran:

gsettings get org.gnome.mutter experimental-features

On Fedora 44, this returned:

@as []

So it's an empty array — neither scale-monitor-framebuffer nor x11-randr-fractional-scaling is present. If I'm understanding your check correctly, that should mean Tiling Shell's internal per-monitor scaling engine is active in this state, not disabled — which is a bit of a puzzle given the bug still shows up. So whatever's going wrong probably isn't this specific gsettings key being set differently on Fedora.

A few things I can do from here if useful:

• Boot into my secondary Ubuntu install on the same hardware and run the identical command for a direct comparison
• Check if there's another config path (e.g. a dconf override, environment variable, or distro-specific default) that might be feeding Mutter a different fractional scaling state than this key reports
• Grab gnome-shell --version and any other diagnostics you need

Let me know what's most useful and I'll get it to you.

Separately (and unrelated to this thread) — I also filed another report about Tiling Shell not remembering per-monitor settings when a display is turned on/off, and the monitor order seeming to reshuffle in the layout dropdown. Keeping that one separate since it looks like a different root cause, just flagging it in case it's useful context.

[domferr]

Thanks!

it's an empty array — neither scale-monitor-framebuffer nor x11-randr-fractional-scaling is present

This is a very useful information.

As per my understanding you have fractional scaling active on Fedora and you are seeing the scaling being applied too much (like twice). Since that array is empty, Tiling Shell assumes fractional scaling is NOT active and proceeds to scale everything. Then Fedora is scaling on its own because fractional scaling IS active but Tiling Shell doesn't know it

[droidleader]

Thanks for bearing with the back-and-forth — here's the full picture, and I think we've nailed down what's actually happening.

GNOME Shell version: 50.2

gsettings result (as reported before):

gsettings get org.gnome.mutter experimental-features
@as []

Empty — neither scale-monitor-framebuffer nor x11-randr-fractional-scaling is present.

But the live state says otherwise. Both ~/.config/monitors.xml and gdctl show (which queries Mutter's live state over D-Bus, not a saved file) agree that a real 1.5 scale is active on my primary monitor:

Logical monitor #2
  Position: (2560, 0)
  Scale: 1.5
  Primary: yes
  Monitors: DP-3 (Wacom Cintiq Pro 24")

This matches monitors.xml exactly — so it's not a stale config left over from a previous session, it's what Mutter is actively applying right now, with the experimental-features key empty.

So it looks like the actual bug is here: on GNOME 50.2 (and possibly earlier versions too), GNOME can apply a real fractional logical-monitor scale — set directly through Settings > Displays — without the scale-monitor-framebuffer flag ever being set in experimental-features. That flag may no longer be the reliable signal it used to be for whether fractional scaling is actually active, at least on this path.

This also probably explains why your own Ubuntu setup didn't catch this: you're running 200%, an integer scale, so the experimental-features flag was never load-bearing for your own fractional-scaling state — your setup never needed to query it in a way that could diverge from reality. My 150% case is exactly the scenario where the flag and the real state disagree.

A possible fix direction, if useful: since gdctl (and the underlying org.gnome.Mutter.DisplayConfig D-Bus interface it wraps) has existed since GNOME 48, Tiling Shell could query the live per-monitor scale directly — checking for any non-integer logical-monitor scale — instead of relying on the experimental-features array. That would catch this case and stay correct regardless of which GNOME version or distro default ships the flag differently.

Happy to test a patch, gather more diagnostics, or boot into my Ubuntu install to run the same three checks there for a direct comparison if that's useful.

(Separate from this thread, flagging again just for context — I also filed a report about per-monitor settings not persisting when a display is power-cycled, plus the layout dropdown seeming to reorder monitors. Keeping that one separate since it looks like a distinct root cause.)

[domferr]

Thanks for sharing. Something is off: fractional scaling is a display setting that allows you to adjust the size of text and UI elements in non-integer increments (e.g., 125%, 150%, 175%). So, if the monitor has a scaling of 1.5, it means fractional scaling is enabled.

GNOME can apply a real fractional logical-monitor scale — set directly through Settings > Displays — without the scale-monitor-framebuffer flag ever being set in experimental-features

Are you sure? To do this you need fractional scaling enabled for what I know. At least this is the behaviour I see on my laptop running GNOME 44 and on a virtual machine running GNOME 47 (on Fedora 41) 🤔

(Separate from this thread, flagging again just for context — I also filed a report about per-monitor settings not persisting when a display is power-cycled, plus the layout dropdown seeming to reorder monitors. Keeping that one separate since it looks like a distinct root cause.)

I'll take a look, thanks! From your explanation it looks like a known bug, I'll share an update there.

[domferr]

A possible fix direction

The one you are proposing should be viable. However, we are interested to react to fractional scaling being enabled or disabled, to rescale everything. We currently do it, but a possible fix to this issue should also consider that we will listen to monitors scaling changes which is not simple. Moreover, we are looking for the fractional scaling setting since this will tell us GNOME will scale by its own on the other monitors and Tiling Shell doesn't have to do it. This means that even with integers scaling factors (2x, 3x, etc...), Tiling Shell should know fractional scaling is enabled to not apply the internal scaling engine.

I'm starting to think that for some reason you have some kind of particular setting that enables fractional setting but without really setting it (experimental feature array is empty)

[droidleader]

Thank you for sharing those thoughts — here are a few more datapoints I think might be helpful in assessing if this is GNOME in general, just Fedora (or my own build), or something Ubuntu would hit too.

GNOME Shell: 50.2

Release notes (https://release.gnome.org/50/, under "Display Handling Improvements"): some distros already enabled VRR/fractional scaling in earlier releases, but for others "these features are now enabled by default in GNOME 50." Fedora 44 and Ubuntu 26.04 LTS both ship GNOME 50 — what version was your Ubuntu test on?

Settings dropdown (screenshot attached): full fractional range listed as selectable (125–375%), not just 100/200 — rules out a stale leftover value.

Raw state:

$ gsettings get org.gnome.mutter experimental-features
@as []

❯ gdctl show | grep -B 4 "DP-3 (Wacom"
Monitors:
├──Monitor DP-3 (Wacom Tech 24")
--
│  ├──Scale: 1.5
│  ├──Transform: normal
│  ├──Primary: yes
│  └──Monitors: (1)
│      └──DP-3 (Wacom Tech 24")

So: empty flag, but a fully valid, live, selectable 1.5 scale. Not sure if that helps to narrow it down, again, if there's something I can do to 'prove/disprove' if this is just my own fedora or a larger issue, please let me know what you think.