Sway: Browser scrolling lag when playing video in unfocused workspace.

[cedws]

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

• I'm not sure it's down to Sway but it seems likely.
• It isn't due to CPU usage.
• I can't produce the issue in firefox or firefox-wayland

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

Steps to produce:

• Open Chromium in workspace 1
• Navigate to a page with a playing video in that workspace (YouTube, any video)
• Move to workspace 2 and open another instance of Chromium
• Navigate to any webpage with a scrollbar
• Keep the cursor still for a couple of seconds anywhere on the page
• Observe that there is a few seconds of lag when attempting to scroll

[Nikki1993]

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]

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

[Nikki1993]

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

[cedws]

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]

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

--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]

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]

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

[Nikki1993]

@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]

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]

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]

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]

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.

[fkjogu]

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]

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]

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]

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]

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]

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.

[fkjogu]

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]

@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]

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]

@qoh That's a known Firefox issue.

[abmantis]

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]

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