Closed tomKPZ closed 1 week ago
not scaling per se, the uv gets fucked.
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.
obviously, it uses chromium?
It uses Electron. I haven't seen other Electron apps (vscodium, spotify, normal webcord) exhibit this issue, so I pointed it out.
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 )
same thing happens for me with all electron apps using wayland with --ozone-platform=wayland
this is a different issue
when will this get fixed?
in the future
https://github.com/hyprwm/Hyprland/assets/81547183/2fa3e9be-9cb0-4535-b7bb-21abb9c225ab
i think it something related to hardware acceleration . mainly in brave browser .
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.
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
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
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.
Still an issue?
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.
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
so thats hyprland regression.
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
add the flag
--disable-features=WaylandFractionalScaleV1
seems fix the issue for me...
Seems like bad implementation on hyprland side
Nice catch
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...
From my case, only scaling=1 is ok, others have display issue like only refreshing a quarter page etc.
Is there a bug report on the Chromium bug tracker to look at? They might not know about this perhaps, sorry for necro posting kinda, but was just curious to be honest. Doesn't happen on other compositors to my knowledge, so perhaps it could be bypassed with a plugin if it bothers people enough, but I assume you don't want to add a workaround for broken applications as it's a Chromium bug
has to be a chromium bug (nothing else has the issue, plus I can inspect the values sent and they definitely are wrong) but I have no clue why it happens
I couldn't find much besides this https://issues.chromium.org/issues/40267260 doesn't seem to be same thing but it is a fractional scaling bug
Created the ticket specifically about this issue: https://issues.chromium.org/issues/337905327 Y'all can click +1 etc. You know how things work with Google.
So was it not Chromium? What should be said on Chromium bug tracker?
I have no clue. I rewrote xdg_shell and I can't see the bug anymore, at least on my end.
nvm, still happens when you dont pass weird flags. Disregard me.
fwiw the fix of using --disable-features=WaylandFractionalScaleV1
doesn't work anymore since this commit (bisect), unfortunately it's a huge one
Interesting
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
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
... 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.
same issue
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.
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..
Is there any progress here, without disabling hardware acceleration? Anybody know whether it's a Hyprland problem or Chrome/Chromium issue?
chromium bug
chromium bug
Hehe, You're funny. Hyprland is only compositor with this bug meanwhile Sway works fine, also wayfire works fine.
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.
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.
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.
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
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.
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)
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...
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
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.
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
This issue seems to occur with Chrome windows at 2x scaling. Issue doesn't occur on sway. See this video for a demo:
https://user-images.githubusercontent.com/9124077/215848089-2769c549-2ee2-4464-9b1f-86e9700f02bb.mp4