search

swaywm / sway

i3-compatible Wayland compositor
https://swaywm.org
MIT License
14.45k stars 1.1k forks source link

Browser scrolling lag when playing video in unfocused workspace. #3716

Open cedws opened 5 years ago

cedws commented 5 years ago

I have been experiencing this issue for a while but only just been able to reproduce it.

If playing a video in Chromium in an unfocused workspace, scrolling will lag in another tab in another workspace.

Steps to produce:

Nikki1993 commented 5 years ago

I had this happen recently but it was apparently caused by intel-media-driver, at some point, it would segfault causing Chromium to lose any kind of hardware acceleration and only force reload would solve it but in the process, any kind of scrolling would be like watching a 10fps slideshow.

Switching to libva-intel-driver and purging intel-media-driver solved it for me.

cedws commented 5 years ago

It looks like I already have libva-intel-driver installed on my system.

Nikki1993 commented 5 years ago

What's the output of vainfo? also, are you using modesetting driver or xf86-intel?

cedws commented 5 years ago

are you using modesetting driver or xf86-intel

I have to be honest, I have no clue. I installed a package named mesa-dri-drivers and that's all.

libva info: VA-API version 1.4.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_4
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.4 (libva 2.4.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Kaby Lake - 2.3.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Simple            : VAEntrypointEncSlice
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointEncSliceLP
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointEncSliceLP
      VAProfileH264MultiviewHigh      : VAEntrypointVLD
      VAProfileH264MultiviewHigh      : VAEntrypointEncSlice
      VAProfileH264StereoHigh         : VAEntrypointVLD
      VAProfileH264StereoHigh         : VAEntrypointEncSlice
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointEncPicture
      VAProfileVP8Version0_3          : VAEntrypointVLD
      VAProfileVP8Version0_3          : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointEncSlice
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointEncSlice
      VAProfileVP9Profile2            : VAEntrypointVLD
Nikki1993 commented 5 years ago

I'd suggest using modesetting driver over xf86-intel. Just run $ pacman -Rns xf86-video-intel to make sure you don't have it installed and make sure you don't have any /etc/X11/xorg.conf.d/20-intel.conf (not sure does it even affect anything under Wayland but I reckon xwayland apps still would).

Seems like you are all good on hardware acceleration front otherwise.

You can also try forcing GPU acceleration under chromium (make sure you are all up-to-date as usual $ pacman -Syu) by creating ~/.config/chromium-flags.conf and then putting the following inside as per arch wiki here https://wiki.archlinux.org/index.php/chromium 

--ignore-gpu-blacklist
--enable-gpu-rasterization
--enable-native-gpu-memory-buffers
--enable-zero-copy
--disable-gpu-driver-bug-workarounds

this will at least give you pretty much the same configuration as I have right now and I haven't experienced a single chromium crash that would result in choppy scrolling afterward due to acceleration dying for some reason.

cedws commented 5 years ago

I'm running Fedora, so I'm not sure what the equivalent package is for xf86-video-intel. A repo search didn't reveal anything like it.

I tried out the Chromium flags but the issue is still present. Also, I haven't experienced any crashes in Chromium, only stuttering/lag.

Thanks.

cedws commented 5 years ago

I still think this is a Swayroots issue. Scrolling doesn't lag if I have two Chromium windows open in the same workspace.

Nikki1993 commented 5 years ago

@c-edw when I mentioned crash I meant the hardware acceleration library. Like for instance to determine if this is the same issue I had you can just open chrome, go to chrome://gpu make sure that says for most of the things hardware accelerated and then once the issue occurs with scrolling re-check chrome://gpu and if it suddenly says software acceleration for everything then it sure sounds like the same issue I had.

P.S. quick googlin showed that Fedoro names that drive as smth like xorg-x11-drv-intel try looking for that and removing it if you have it. Modesetting driver in most of the instances is miles better.

cedws commented 5 years ago

I'm going to close this and will reopen if I can demonstrate that it's a Sway issue. It is starting to look like a hardware acceleration issue but it's unclear why the lag only happens with another instance of Chromium in another workspace.

ascent12 commented 5 years ago

I have a suspicion that this is related to implicit synchronisation. Without going into too much technical detail, we sometimes end up blocking waiting for a client to finish drawing, and could possibly cause us to miss a frame on another output, making it stutter. I have a worst-case video file with mpv (10000x10000 pixels) that can cause extreme lag when it tries to play, even with quite a low CPU usage. The somewhat new wp_linux_explicit_synchronization extension is an avenue for fixing this, as we could then guarantee that we never block on clients. This is something I plan to implement in wlroots.

However, this is purely conjecture. I don't have any way to verify that this is the cause of the issue.

cedws commented 5 years ago

If that were the cause, what would the stutter look like? If it's a single frame then the stutter surely wouldn't be too severe. With this issue, the stutter can be over a second long.

I should really get a recording of it...

cedws commented 5 years ago

Here's a video of it. (link dead)

These two windows are in different workspaces. The cursor is shown on both windows at the same time for some reason.

The issue is most visible around 1:00. There's a blank YouTube video playing on the right, and the mouse events are delayed by ~1s.

clamydo commented 5 years ago

I have a similar or the same issue: Using Firefox 66.0.3 on Arch Linux with the official sway-1.0 package, with intel kms driver and having OMTC force-enabled (layers.acceleration.force-enabled=true), playing a video in the foreground is fine. But when having a second window of Firefox either in a new workspace or below the other both start to lag massively. Does not happen, if they are side by side.

This does not happen with Gnome Wayland! It also does not happen with the software render of Firefox (no OMTC) or for example Chromium. So I suppose this really is an issue with sway and hardware accelerated rendering in Firefox. So please, @c-edw reopen the issue. I am happy to provide logs or whatever information is needed!

Here is a log: https://pastebin.com/2W9mJ84Q

Mel34 commented 5 years ago

I have a similar or the same issue: Using Firefox 66.0.3 on Arch Linux with the official sway-1.0 package, with intel kms driver and having OMTC force-enabled (layers.acceleration.force-enabled=true), playing a video in the foreground is fine. But when having a second window of Firefox either in a new workspace or below the other both start to lag massively. Does not happen, if they are side by side.

Confirming this, except I'm using AMD Rx580 and webrender in ffox.

cedws commented 5 years ago

Interesting. This is almost certainly independent of browser/codecs/drivers then. I think it's what you suggested it could be @ascent12. Is there an issue open on wlroots for this?

lnikkila commented 5 years ago

I'm also seeing this on an Intel system, I've noticed that it also happens when there's anything on a web page that updates like a spinner or a timer, not just video. I have two Firefox windows open on two different workspaces. If there's any info I could give that might be useful, just let me know.

I'm not sure if this is related, but I'm also seeing high CPU usage on Firefox when I move my cursor at all or scroll the page. I don't see this in other applications, including Xwayland ones, so I've reported it to Firefox here: https://bugzilla.mozilla.org/show_bug.cgi?id=1557933

cedws commented 5 years ago

I found recently that exporting environment variable vblank_mode=0 fixes this for me (export vblank_mode=0 in my .zshenv). Though, it apparently disables vsync in Mesa, so maybe it counts as a workaround rather than a fix and would explain why my laptop fan goes nuts at regular intervals. @lnikkila Mind giving this a go and reporting back?

lnikkila commented 5 years ago

Wow, seems like that fixed it for me too. However the CPU usage issues in Firefox when redrawing persist, so it seems like these are two separate issues.

clamydo commented 5 years ago

Nice find! I can confirm disabling vsync in the driver helps. But setting the VBLANK_MODE environment variable did not work for me using an Intel GPU (HD Graphics 520, Skylake, modesetting driver from mesa). I had to disable it in ~/.drirc,

<device screen="0" driver="dri2">
    <application name="Default">
        <option name="vblank_mode" value="0"/>
    </application>
</device>

as described in https://wiki.archlinux.org/index.php/Intel#Disable_Vertical_Synchronization_(VSYNC). I am not sure about possible side-effects though. Testing it for a while.

I am also a bit confused about the driver="dri2" bit. I thought the system was using DRI3.

cedws commented 5 years ago

@fkjogu I think the environment variable needs to be lowercase (vblank_mode not VBLANK_MODE). Make sure that the variable is exported and that you source/re-login to the TTY which you launch sway from.

As for side effects, disabling vsync is obviously unoptimal because your GPU is doing unnecessary work. It will probably kill battery life.

qoh commented 4 years ago

On amdgpu, any Firefox (MOZ_WAYLAND_ENABLE=1) window other than the primary (originally opened by launching) performs very poorly (single digit framerate, high latency) whenever the primary window is not shown (in a background workspace). Having the primary in an unfocused but visible workspace on another monitor works fine.

Very unsure whether it's related to this, but this is the closest issue I could find.

ascent12 commented 4 years ago

@qoh That's a known Firefox issue.

abmantis commented 4 years ago

Also can confirm that setting vblank_mode=0 fixes the problem for me. Without it, having a video playing in a workspace that is not visible makes all Firefox windows very slow.

pbartyik commented 4 years ago

I also face this when putting the window that is running the video into scratchpad. setting vblank_mode=0 helps. Running intel integrated GPU.

mntmn commented 3 years ago

Setting vblank_mode=0 fixes all my problems related to this as well on Radeon RX 580 (POLARIS10), Mesa 20.2.6. Before, I couldn't use chromium with multiple windows not on the same workspace (it would get unusably slow), and I was suffering from click/input delays when distributing KiCAD windows on multiple workspaces.

emersion commented 3 years ago

vblank_mode=0 isn't a very good workaround, it makes the clients render at full speed without any throttling, basically maxing out GPU usage.

mntmn commented 3 years ago

But I can finally do my job without suffering! What else do you suggest? (I can't stress enough how unergonomic it was before, I was about to look for another DE)

emersion commented 3 years ago

Ideally clients should be fixed. There are other workarounds being discussed, e.g. https://gitlab.freedesktop.org/mesa/mesa/-/issues/4932.

ficcdaf commented 8 months ago

3 years later, can confirm that the issue still persists.

crmtestresco commented 6 months ago

I also can confirm the issue is still present

geogeim commented 5 months ago

issue still persists, very annoying. vblank_mode=0 fixes it for me debian, gnome, intel 520 graphics

crmtestresco commented 5 months ago

Interesting thing is, this does not happen on Manjaro system. No idea, what the underlying difference is