-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In tabbed layout, multiple browser windows slow each other down. #5723
Comments
Can you provide a WAYLAND_DEBUG=1 your-client >client.log 2>&1
# Then reproduce the bug This is likely a client bug. |
|
Eh, seems like it's using X11. I don't see anything to be done here... |
This doesn't happen on i3. |
I can reproduce this issue on qutebrowser, too. |
Since this happens on X11 this may be related to Xwayland, can you try to reproduce this within Weston? |
@Emantor This is only reproducible in tabbed layout. It is not reproducible in split layouts. Weston is not a tiling window manager. This issue is reproducible on qutebrowser which is a Qt program when Qt backend is XCB. When Qt backend is wayland, this issue doesn't occur on qutebrowser. |
I couldn't reproduce the issue in weston-launch. This issue is reproducible in tabbed layout. |
This is kind of happening on GNOME as well - if I open two Chrome/Chromium/Brave windows and full screen them, there seems to be noticeable lag to either of the windows - just saying that this is quite probably an issue with XWayland and not Sway itself |
Same problem at Chrome(xwayland) since version 85. |
I try to use Chrome-ozone(wayland) to avoid this issue, but it can't support IME, so sad... |
@Me7426 what is IME? |
Input Method :) |
wayland input method support is still in its infancy. Don't expect it to work on wayland clients. |
This issue is also reproducible on firefox, too. |
Reproducible with Chromium 103:
This makes me think that Chrome window A doesn't "get the message" at step 2 that it's actually in the background, and doesn't suspend page rendering. This seems confirmed by Page Visibility API test at http://daniemon.com/tech/webapps/page-visibility/. The browser Page Visibility API tells a page when it's not visible. In the test, if you switch to another tab, video pauses, but if you switch to another WM tab or workspace, video keeps going, meaning that the page still thinks it's visible. You might not notice this on machines with more than 2 cores (but your battery probably will). |
There is no "visibility" API in Wayland. Instead, invisible windows stop getting |
@emersion never said there was one; I wrote: "The browser Page Visibility API tells a page when it's not visible". (https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API) I mentioned it because it helps confirm that the browser thinks the window is still visible, more precisely than just inferring it from the slowdown. I'm not making hypotheses as to why the browser thinks so. |
I have a feeling this also breaks twitch streaming. (which is broken on sway/chrome. just start a stream and switch desktops, after a minute or so it'll stop playing in the background) The browser gets rate limited by sway because it's off screen, but never gets told it's off-screen because wayland hasn't made any progress on the surface suspension API. This means the streaming hasn't stopped rendering or adapted its rate (because it doesn't know it's off-screen), however because the window is only getting frame events at 1Hz, it stalls out the entire application causing the stream to be delayed and eventually stop rendering at all after about a minute. |
Sway Version: 392d480
Debug Log: sway.log
Configuration File: config.minimal.txt
Description:
Ctrl+N
The text was updated successfully, but these errors were encountered: