Fractional Scaling Artifacts | Background Bleeding

[tekstryder]

Hyprland version

All tagged versions of hyprland since v0.49.0 when I jumped aboard, including v0.53.1.

Currently on today's git:

Hyprland 0.53.0 built from branch main at commit 107275238c0dd5e3de8b9c36575a335ebd393c56 dirty (desktop/ls: clamp layer from protocol).
Date: Mon Jan 5 12:53:29 2026
Tag: v0.53.0-31-g107275238, commits: 6787

Libraries:
Hyprgraphics: built against 0.5.0, system has 0.5.0
Hyprutils: built against 0.11.0, system has 0.11.0
Hyprcursor: built against 0.1.13, system has 0.1.13
Hyprlang: built against 0.6.7, system has 0.6.7
Aquamarine: built against 0.10.0, system has 0.10.0

Version ABI string: 107275238c0dd5e3de8b9c36575a335ebd393c56_aq_0.10_hu_0.11_hg_0.5_hc_0.1_hlg_0.6
flags set:
no xwayland

Regression

No

Describe the bug

Background bleeding thru browser UI. This one drives me abso-frikken-lutely BONKERS.

It's very distracting, so if I'm planning to be a browser jockey for a while I just go use Sway instead.

Due to a separate scaling issue (#11099), I cannot use 1.25 scaling factor.

The only other reasonable scale for my display is 1.33. It's actually better for my aging eyes.

• This issue occurs at 1.33 scale factor
• I've not been able to repro at 1.25. Other scaling factors untested/irrelevant.

Reproduction steps

1. Scale monitor to 1.33 factor
2. Open latest Brave or Chromium browser as the single window on a workspace with no borders
3. Toggling floating can help exacerbate but is not necessary for the issue to manifest
4. Note distracting corruption of 1px row of pixels show/flash/twinkle/disappear betwen tab bar and address bar

I set my background to solid red to demonstrate.

In addition to the background bleeding through, a thin black line often appears when moving the mouse around, often after opening a context menu.

The pixels seem to be unsure whether they should even be there, as it's all glitchy with pixels flickering, coming and going.

screencast-2026-01-05_16-29-35.mp4

Does not occur on:

• sway git + container, transaction: align to fractional grid swaywm/sway#8715
• wlroots git + scene: use position independent scaling

Coincidentally... those MRs solve a very similar 1px flickering scaling issue:

• Row of random pixels at bottom/right of output using wlr_scene with certain fractional scales

System info and config

• Display (PHL 328E1): 3840x2160 @ 1.33x in 32", 60 Hz
• Display (DELL U2711): 1440x2560 @ 1.07x in 27", 60 Hz

monitor = DP-1, 3840x2160, 0x0, 1.333333
monitor = DVI-D-1, 2560x1440, 2880x-425, 1.066667, transform, 3

hyprsysinfo.txt

[tekstryder]

I've employed a very crude workaround for now.

I set brave/chromium flag --force-device-scale-factor=0.99.

Seems to trick the math just enough to make this fractional scaling issue "disappear".

Of course this now causes the same issue under Sway.

I'll need to manage two separate .desktop files until this is fixed properly in the Hyprland renderer.

[tekstryder]

Instead of separate *.desktop files for each environment, I'm replacing brave-flags.conf at session start rather.

# Due to Hyprland scaling issue, copy unique flags for Hyprland
exec-once = bash -c "cp -a /home/tekstryder/.config/brave-flags-hypr.conf /home/tekstryder/.config/brave-flags.conf"

And the same, but opposite, when launching Sway.

A hacky "solution" && a crude workaround.

Hopefully the actual scaling issue can be addressed in Hyprland.

[Don-Keehotee]

I have this problem with latest chromium 144.0.7559.96 too.

On Hyprland v0.53.3 release tag.

[tekstryder]

@jmanc3 any chance #13124 will help here?

Love seeing any and all scaling artifact issues squashed.

EDIT: It does not affect this issue unfortunately.

[Unidentified01]

Reached 5 likes, you should be able to ping a member about this now

[tekstryder]

They see the discussions.

I try not to ping unless stuff's really broken ;)

[vaxerski]

I fail to see how this could be possible without chromium actually rendering a 1px transparent hr

[tekstryder]

Dunnoh, but it doesn't occur at 1.0x or 1.25x scaling. Just with 1.33x here.

Anyhow, given I have 3 unsolved scaling issues in Hyprland, I've implemented another workaround...

Set debug:disable_scale_checks and set scaling factors to 1.35 and 1.05 respectively.

monitor = DP-1, 3840x2160, 0x0, 1.35
monitor = DVI-D-1, 2560x1440, 2845x-455, 1.05, transform, 3

These happen to be the same scaling factors I use on Sway without issue as well.

Works around this problem, #11099, and new regression #13119.

Also provides a near-perfect PPI match between my two displays, so win/win.

[tekstryder]

Marking this as answered by the fact that such scaling issues are inherent in Wayland compositors at this time.

Full writeup over on the Sway Gitlab with detailed findings of hundreds of scaling factors tested.

Perhaps we can look forward to future work with the xx-fractional-scale-v2 proposal for an alternate way to handle fractional scaling:

• https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/499

This ultimately came down to finding the sweet spot of:

1. scaling factors that are easy on the eyes
2. scaling factors that result in a good PPI match between displays of different dimensions/resolutions
3. finding scaling factors that satisfy 1 & 2, but do not cause this pixel corruption issue.

------------------
---- MONITORS ----
------------------

-- Native --
-- hl.monitor({
--     output    = "DP-1",
--     mode      = "3840x2160",
--     position  = "0x0",
-- })
-- hl.monitor({
--     output    = "DVI-D-1",
--     mode      = "2560x1440",
--     position  = "3840x-225",
--     transform = 3
-- })


-- Small --
-- hl.monitor({
--     output    = "DP-1",
--     mode      = "3840x2160",
--     position  = "0x0",
--     scale     = 1.283
-- })
-- hl.monitor({
--     output    = "DVI-D-1",
--     mode      = "2560x1440",
--     position  = "2994x-472",
--     transform = 3
-- })


-- Medium --
-- hl.monitor({
--     output    = "DP-1",
--     mode      = "3840x2160",
--     position  = "0x0",
--     scale     = 1.341
-- })
-- hl.monitor({
--     output    = "DVI-D-1",
--     mode      = "2560x1440",
--     position  = "2864x-446",
--     scale     = 1.050,
--     transform = 3
-- })


-- Large --
hl.monitor({
    output    = "DP-1",
    mode      = "3840x2160",
    position  = "0x0",
    scale     = 1.400
})
hl.monitor({
    output    = "DVI-D-1",
    mode      = "2560x1440",
    position  = "2744x-420",
    scale     = 1.100,
    transform = 3
})


-- Huge --
-- hl.monitor({
--     output    = "DP-1",
--     mode      = "3840x2160",
--     position  = "0x0",
--     scale     = 1.500
-- })
-- hl.monitor({
--     output    = "DVI-D-1",
--     mode      = "2560x1440",
--     position  = "2560x-396",
--     scale     = 1.175,
--     transform = 3
-- })