Incorrect chromium wayland uv while resizing window

[tomKPZ]

This issue seems to occur with Chrome windows at 2x scaling. Issue doesn't occur on sway. See this video for a demo:

2023-01-31.10-17-24.mp4

[vaxerski]

not scaling per se, the uv gets fucked.

[TheSunCat]

This same issue can be reproduced with WebCord from the AUR package webcord-git-screenshare when running as Wayland native. I am using a scaling of 1.4x.

[vaxerski]

obviously, it uses chromium?

[TheSunCat]

It uses Electron. I haven't seen other Electron apps (vscodium, spotify, normal webcord) exhibit this issue, so I pointed it out.

[ghost]

discord and chromium experience the same issue
this is without any scaling
cant recreate outside of using mouse resizing
cant recreate on other window types (any qt, firefox, alacritty)

chrome will eventually correct itself soon after the mouse lets go when resizing
discord does not always recover and can often become blurry out of space and or entirely broken ( this is the regular discord client not some mod )

[aalhitennf]

same thing happens for me with all electron apps using wayland with --ozone-platform=wayland

[vaxerski]

this is a different issue

[fybx]

when will this get fixed?

[vaxerski]

in the future

[random2907]

output.mp4

i think it something related to hardware acceleration .
mainly in brave browser .

[fybx]

output.mp4
i think it something related to hardware acceleration . mainly in brave browser .

Which external graphics driver does Brave use? I am on an Arch machine with AMD integrated graphics (I've not installed a single graphics driver explicitly since Linux kernel has native AMD graphics implementation) and have had this Chromium (& electron) issue for a long time.

[random2907]

output.mp4
i think it something related to hardware acceleration . mainly in brave browser .

Which external graphics driver does Brave use? I am on an Arch machine with AMD integrated graphics (I've not installed a single graphics driver explicitly) and have had this Chromium (& electron) issue for a long time.

I don't install anything it's intel igpu 12th gen I currently noticed in intel_gpu_top that it not using gpu it causing the cpu but un gpu section it shows that hardware acceleration enabled but it's not it's broken on all chromium browser and fully disabling gpu acceleration it fix the ux and graphical glitch means hardware acceleration is partly broken there is issue report on brave github

[nooneyy]

I managed to fix this on my machine by creating ~/.config/brave-flags.conf and putting this in it:

--ozone-platform-hint=wayland
--use-gl=egl

--use-gl=egl being the one that fixed it.

Edit: nevermind, that disables gpu acceleration

[random2907]

I managed to fix this on my machine by creating ~/.config/brave-flags.conf and putting this in it:

--ozone-platform-hint=wayland
--use-gl=egl

--use-gl=egl being the one that fixed it.

Edit: nevermind, that disables gpu acceleration

yes the hardware acceleration is broken.

[Edgars-Cirulis]

Still an issue?

[TheSunCat]

Yup. As long as you have hw acceleration on a Chromium/Electron app and it runs as Wayland, it will stretch the wrong way on resize.

[Edgars-Cirulis]

Yup. As long as you have hw acceleration on a Chromium/Electron app and it runs as Wayland, it will stretch the wrong way on resize.

Not a case in wlroots or kde using wayland

[Edgars-Cirulis]

so thats hyprland regression.

[BRS5672023]

add the flag --disable-features=WaylandFractionalScaleV1 seems fix the issue for me...

well, I find this flag breaks chromium display contents (especially on scrolling) on my laptop for scaling is set to 2...

it seems now this workaround no longer works on chromium 126 see #6552

[vaxerski]

I have no clue. I rewrote xdg_shell and I can't see the bug anymore, at least on my end.

[vaxerski]

nvm, still happens when you dont pass weird flags. Disregard me.

[danimateo]

fwiw the fix of using --disable-features=WaylandFractionalScaleV1 doesn't work anymore since this commit (bisect), unfortunately it's a huge one

[nonetrix]

Interesting

[fybx]

Yup. As long as you have hw acceleration on a Chromium/Electron app and it runs as Wayland, it will stretch the wrong way on resize.

Not a case in wlroots or kde using wayland

+ KDE and GNOME with Wayland doesn't have this

[nonetrix]

On unrelated note Chromium likes to stay locked at 60 FPS despite being on my 165Hz monitor a lot, I had that issue on X too I think Chromium is just being dumb not sure if that is known issue or not. Of course on Windows just works though and Firefox no issue whatsoever :/

Linux and especially Wayland seems like joke to Google lol

[fybx]

... Windows just works though and Firefox no issue whatsoever :/

Linux and especially Wayland seems like joke to Google lol

I gave up using Windows completely when it decided to nuke my ESP, and Chromium (was ungoogled-chromium ofc) because of the insufficient (and reluctant) support for Wayland.

They can both go to hell.

[sdutwsl]

same issue

[Azarattum]

Is there any change to fix this without disabling hardware acceleration in the browser? The artifacts are really annoying and ruin satisfaction from the animations. I would say, this bug is my №1 issue with Hyprland right now.

[BRS5672023]

Is there any change to fix this without disabling hardware acceleration in the browser? The artifacts are really annoying and ruin satisfaction from the animations. I would say, this bug is my №1 issue with Hyprland right now.

I'm using the windowrule windowrulev2=noanim,class:^(chromium)$,title:(- Chromium)$ to turn off the animation for now, while it behaves strangely when I drag a tab and detach it, which I now use the shortcut Ctrl+PageUp/PageDown and Ctrl+Shift+PageUp/PageDown to interact with tabs..

[CyanChanges]

Is there any progress here, without disabling hardware acceleration?
Anybody know whether it's a Hyprland problem or Chrome/Chromium issue?

[vaxerski]

chromium bug

[Edgars-Cirulis]

chromium bug

Hehe, You're funny. Hyprland is only compositor with this bug meanwhile Sway works fine, also wayfire works fine.

[suderman]

Chromium/Electron is a glitchy mess on my nvidia Hyprland desktop, including this experience. Workaround is to force Xwayland in all Chromium apps. This fixes everything except now I have to deal with zooming/upscaling (else everything is tiny on my high res screen) and the loss of dragndrop. But 90% good.

[Azarattum]

This issue is also present in many electron apps. So, even if chromium fixes it, it will be a while until all the apps update. If any reasonable workaround is possible on the compositor side, that would be great.

[suderman]

I keep Wayland on my non-nvidia Intel integrated graphics laptop, because it's 99% solid. Only remaining issue is the visual glitches during Chromium window resize, but I can live with that.

[vaxerski]

Hehe, You're funny. Hyprland is only compositor with this bug meanwhile Sway works fine, also wayfire works fine.

doesn't mean it's a hyprland bug. Chromium is the only one with this bug.

My guess is chromium shits itself if it receives multiple resize requests before it has a chance to repaint fully

[Edgars-Cirulis]

Hehe, You're funny. Hyprland is only compositor with this bug meanwhile Sway works fine, also wayfire works fine.

doesn't mean it's a hyprland bug. Chromium is the only one with this bug.

My guess is chromium shits itself if it receives multiple resize requests before it has a chance to repaint fully

I've looked into source code, found the issue. The current implementation handles static geometry and viewport changes, but doesnt adapt to real time size changes in calculateUVForSurface also not sure about that, maybe call calculateUVForSurface on renderWindow ? So no Vaxry its not Chromium issue.

[fybx]

Hehe, You're funny. Hyprland is only compositor with this bug meanwhile Sway works fine, also wayfire works fine.

doesn't mean it's a hyprland bug. Chromium is the only one with this bug.
My guess is chromium shits itself if it receives multiple resize requests before it has a chance to repaint fully

I've looked into source code, found the issue. The current implementation handles static geometry and viewport changes, but doesnt adapt to real time size changes in calculateUVForSurface also not sure about that, maybe call calculateUVForSurface on renderWindow ? So no Vaxry its not Chromium issue.

any chance of a PR? (kindly asking)

[Edgars-Cirulis]

Hehe, You're funny. Hyprland is only compositor with this bug meanwhile Sway works fine, also wayfire works fine.

doesn't mean it's a hyprland bug. Chromium is the only one with this bug.
My guess is chromium shits itself if it receives multiple resize requests before it has a chance to repaint fully

I've looked into source code, found the issue. The current implementation handles static geometry and viewport changes, but doesnt adapt to real time size changes in calculateUVForSurface also not sure about that, maybe call calculateUVForSurface on renderWindow ? So no Vaxry its not Chromium issue.

any chance of a PR? (kindly asking)

Ehh. I could but what's the point here if Vaxry will always say it's XWayland / Electron / Chromium / Nvidis issue. If we know that it dosnt happen on any other wayland compositor...

[nonetrix]

Sounds like easy fix at least hopefully if true, I guess someone else could look into it I'm too dumb unfortunately. Anymore pointers or anything perhaps though maybe? But also why is Chromium doing that in first place when no other applications seem to lol? Reminds me of Gamescope situation if you are to be believed of course

[vaxerski]

there is no reason for me not to accept a pr that fixes stuff. I doubt it's on hyprland's side but I'm open to be proven wrong.

[fybx]

Hehe, You're funny. Hyprland is only compositor with this bug meanwhile Sway works fine, also wayfire works fine.

doesn't mean it's a hyprland bug. Chromium is the only one with this bug.
My guess is chromium shits itself if it receives multiple resize requests before it has a chance to repaint fully

I've looked into source code, found the issue. The current implementation handles static geometry and viewport changes, but doesnt adapt to real time size changes in calculateUVForSurface also not sure about that, maybe call calculateUVForSurface on renderWindow ? So no Vaxry its not Chromium issue.

any chance of a PR? (kindly asking)

Ehh. I could but what's the point here if Vaxry will always say it's XWayland / Electron / Chromium / Nvidis issue. If we know that it dosnt happen on any other wayland compositor...

the point is the benefit of the open source community/hyprland community IMHO

[Edgars-Cirulis]

there is no reason for me not to accept a pr that fixes stuff. I doubt it's on hyprland's side but I'm open to be proven wrong.

Alright, I'll make pull request whenever I'm free from work.

September 19 Update: Tomorrow I'm free.
I'm free tomorrow at September 20