Picom lags while dragging a video which is loading

DarkNaaz commented 3 years ago

Platform

Arch Linux amd64

GPU, drivers, and screen setup

Nvidia GTX 1070, nvidia-drivers 460.56, single monitor

glxinfo.txt

Environment

Openbox

picom version

vgit-a8445

Configuration:

picom.conf.txt

Steps of reproduction

Open a youtube video and skip to a part which isnt loaded
Drag or resize any window

Expected behavior

It shouldnt lag

Current Behavior

It keeps lagging, i tried using different backends but none of them fix the problem

Other details

Here is a video of the problem https://youtu.be/T84nznI5rRM

kwand commented 3 years ago

I'm also having this same issue. Though, since I've been playing around with NVIDIA's Nsight System's profiler, I tried to gather some data thanks to @DarkNaaz's video.

And I seem to have found the culprit, but not the cause. Picom seems to block/waiting doing polling multiple times every time we skip to a part that isn't loaded in YouTube's video player. I'm not certain if this is YouTube's problem (their video player) or Chrome (assuming that is indeed Chrome being used in the video) and its interaction with the X server (or other components that Picom interacts with).

(I'm happy to provide more profiling results if anyone wants to take a look at whatever code is causing this. This unfortunately is currently beyond my ability, both in familiarity with the codebase and in time)

kwand commented 3 years ago

I've figured out what the problem is. Unfortunately, it seems to be Chrome and however they seem to be handling video rendering or at least communicating with the X server.

I repeated the same test in Firefox (play a 4K video - to increase loading times - on YouTube and move the window around while periodically skipping to an unloaded section) and there was pretty much no observable lag.

From profiling (in Nsight Systems), Picom seems to hang whenever we call anything from xcb - there doesn't seem to be a particular function/method that's causing this. For example, here's some of the things picom seems to be doing (from stack trace) before it goes and hangs on polling:

Hanging from polling in x_fence_sync in backend.c. Libxcb seems to internally call xcb_request_check which causes us to block for a full frame (16ms). https://i.imgur.com/ZGEBamy.png
Hanging in handle_pending_updates. Libxcb internally calls xcb_send_request_with_fds64 - which was the last traced call before the polling event. Whatever is going on inside libxcb again causes almost a full frame of blocking (15ms). https://i.imgur.com/tOsWVPZ.png

(These traces are from my current fork - since I've already set up profiling for it, but I've confirmed that this is an issue that exists in the next branch and vgit-dac85. And again, this seems to have been caused by Chrome)

Unfortunately, I wasn't able to profile with finer samples in Nsight (already set sampling rate to its max), so it seems like I'm missing stack traces for a lot of polling calls. In the above two images, you should notice that I have no idea what the other 16-17ms polling events are caused by. Some poll for even longer, which I also don't have stack traces for.

Now, I don't quite understand how the X server works, but I suspect that Chrome is either somehow overwhelming it or preventing it from responding to other clients - or at least picom.

EDIT: Just tested the same thing on vimeo - and sure enough, lag. So, it appears this is indeed a Chrome video-rendering specific issue, and not just a Chrome-YouTube combination. Not sure if it is Nvidia-specific and/or Chromium specific as well. (I'll try testing other Chrome-based browser later, but I don't have anything running non-Nvidia drivers ATM)

EDIT 2: Seems to be a Chrome-based problem in general. At least, Microsoft Edge (dev build) seems to have the same problem as well.

EDIT 3: Vivaldi (another Chrome-based browser) has this problem as well. It seems that all Chromium-derived browsers possibly suffer from this problem.

Elserjo commented 3 years ago

I have exact same problem in Firefox https://github.com/yshui/picom/issues/366

GTX 1070. Arch.

kwand commented 3 years ago

I have exact same problem in Firefox #366

GTX 1070. Arch.

OK, I've spent the last hour trying to debug your issue and you seem to be correct that with OMTC enabled, there are video lag problems.

However, I still don't quite understand why you need to use OMTC - could you give some examples of where tearing occurs without OMTC enabled? (Your videos from the other issue no longer seem to play)

Also, while doing the testing and some research, it appears that these issues are not necessarily browser-related, but rather it appears that it's due to the browsers using CPU/software decoding and rendering. Chrome and all Chromium-based browsers apparently do not support hardware video acceleration - and this is noticeable both by high CPU usage and online documentation. (There are apparently workarounds with chromium-vaapi, but apparently, it doesn't always work)

I'm not quite sure about Firefox, but it seems like using layers.acceleration.force-enabled might not be the right way to get hardware acceleration for video - enabling that flag seems to have some undesired effects when it comes to video. Have you tried these settings for video acceleration? Also, have you tried the different backends that exist for Firefox?

(Note: I'm talking about Firefox backends - WebRender or OpenGL; see Arch wiki - NOT picom backends. Though, I would suggest you do your testing on picom with --experimental-backends, on the current git next branch, as there (allegedly) have been some improvements to general window movement since the last October release)

I'm starting to think this might not be picom related - or at least, a fix will be very difficult to produce from modifying picom alone.* This seems heavily tied to hardware-acceleration support in browsers, which unfortunately have been not that great for Linux so far.

(*By-the-way, it seems that Windows 10 does have a 'workaround' for this issue - assuming they also suffer from this issue (but it's impossible to tell, seeing what their 'workaround' is) - as it ensures smooth window dragging at the expense of freezing the video, or possibly the entire window. It might be possible to implement a similar solution in picom, but personally, I would hardly call this an improvement.)

EDIT: Perhaps I spoke too soon. I seem to have been able to enable hardware acceleration on proprietary Chrome - still lagging unfortunately. Still no idea how to enable it on Chromium, but I suspect it's not going to be any better than on Chrome.

Elserjo commented 3 years ago

However, I still don't quite understand why you need to use OMTC - could you give some examples of where tearing occurs without OMTC enabled? (Your videos from the other issue no longer seem to play)

First of all, thank you for answer. I may agree with you, it's was old topic and it was tested with glx backend. Now i have been using xrender backend, and i see tearing much less.

It was tested with both Firefox backends: OMTC and Webrender. Both are laggy.

Also, while doing the testing and some research, it appears that these issues are not necessarily browser-related, but rather it appears that it's due to the browsers using CPU/software decoding and rendering.

I think so. I also have problems with mpv, when is compositing enabled. (bypass compositor option "x11-bypass-compositor=yes"). I have made little example for you https://disk.yandex.ru/d/f92QhayZ_SaqJA (with compositor enabled) https://disk.yandex.ru/i/2OCvX2lQSHlQoA (without compositor bypass). Dragging is smooth, but there is tearing.

It was tested with xrender picom backend.

Windows 10 does have a 'workaround' for this issue - assuming they also suffer from this issue (but it's impossible to tell, seeing what their 'workaround' is) - as it ensures smooth window dragging at the expense of freezing the video, or possibly the entire window.

it's strange. Windows hasn't got any problems with tearing and i have never noticed it.

Beyley commented 3 years ago

I seem to be getting the same issue in librewolf where when i have a video playing at all (not just when loading) what happens in the original video happens to me, ive tried with the setting in about:config but that doesnt seem to change anything

EDIT: after a restart it seems to be fixed??

raphaelr commented 3 years ago

I just upgraded from (chromium-based) brave-browser 1.29.80 to 1.29.81, and now this issue is fixed on my system. I assume there was a bugfix on Chromium's side. If I downgrade to 1.29.80, dragging is laggy again.

System: Debian Testing using Xorg and the proprietary nvidia driver on a RTX 2070, picom 8.2-1

yshui / picom