Open Bug 1703529 Opened 4 years ago Updated 2 years ago

Low frame rate while smooth scrolling when picture-in-picture video is active

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
Firefox 87
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: andysem, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(5 files)

about:support page contents
44.18 KB, text/plain
Details
Firefox 2021-04-12 22.34 profile.json.gz
5.78 MB, application/gzip
Details
about:support page contents with EGL enabled
46.86 KB, text/plain
Details
Firefox 2021-09-21 22.35 profile.json.gz
5.97 MB, application/gzip
Details
Screencast 2021-09-21 23_10_11.mkv
6.19 MB, video/x-matroska
Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

  1. Have smooth scrolling enabled in Firefox settings.
  2. Open any Youtube (or any other site) video and start playback.
  3. Click on the icon to enable picture-in-picture mode.
  4. Switch to another tab, open a web page and try scrolling through it with the mouse wheel.

Actual results:

The scrolling is noticeably less smooth than when picture-in-picture is not active, as if the frame rate is cut in half. A few observations:

  • The picture-in-picture video is played back normally, the video frame rate seems normal.
  • CPU is not fully loaded when the video is being played, nor when I scroll the page. This does not seem like a CPU shortage.
  • The scrolling becomes smooth again when the video in picture-in-picture mode is paused or returned to the normal, in-page mode and that page tab is in the background (i.e. when I switch away from the tab with the playing video).

This is on Firefox 87.0 (but was reproducible on previous releases, since the introduction of picture-in-picture mode, AFAIR). Kubuntu 20.10, Nvidia driver 465.19.01 (also, not specific to Kubuntu or Nvidia driver version). WebRender is enabled, but reproduces without it as well.

Expected results:

Picture-in-picture video should not affect the scrolling smoothness as long as there is enough CPU/GPU resources.

Summary: Low frame in smooth scrolling rate when picture-in-picture video is active → Low frame rate while smooth scrolling rate when picture-in-picture video is active
Summary: Low frame rate while smooth scrolling rate when picture-in-picture video is active → Low frame rate while smooth scrolling when picture-in-picture video is active

The Bugbug bot thinks this bug should belong to the 'Toolkit::Video/Audio Controls' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Video/Audio Controls
Product: Firefox → Toolkit
Component: Video/Audio Controls → Audio/Video: Playback
Product: Toolkit → Core

I think this is happening because the background tab is getting deprioritized though I thought we had some special code to keep the video frames playing at normal frame rate when in PiP.

Please note that video playback in PiP is at normal frame rate. It's the non-video tab that is on the foreground which I'm scrolling that has low frame rate.

Ah okay thanks for that clarification.

Component: Audio/Video: Playback → Panning and Zooming

Can you upload a profile using https://profiler.firefox.com/ and the Firefox Graphics preset of a short span where the problem is happening?

Flags: needinfo?(andysem)

Here is a profile that was collected while playing a video in PiP mode and scrolling this bug page.

Flags: needinfo?(andysem)

Thanks.

The profile has a lot of dropped frames markers, seems like almost half of all video frames are dropped? Which seems weird since you said that the video seems fine. Perhaps it's less noticeable in the video? I'm not sure. So maybe we are just struggling to put that many frames on the screen? Moving to graphics under that hypothesis to get a look.

Component: Panning and Zooming → Graphics
Blocks: wr-linux
Severity: -- → S4

Bug 1682206 might be related here.

See Also: → 1682206

This should be fixed by switching to EGL

Depends on: linux-egl

Driver Vendor: nvidia/unknown

Blocks: wr-nv-linux
No longer blocks: wr-linux
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
No longer depends on: linux-egl
Resolution: --- → DUPLICATE
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

This does not seem like a duplicate. The referenced bug cites enabling EGL as the solution/workaround, and it does not help in my case. I tried starting Firefox with MOZ_X11_EGL=1, about:support says "force_enabled by user: Force enabled by envvar" for X11_EGL, and the issue reproduces exactly as described in the initial post.

I'm on Nvidia driver 470.74 now.

Here is the fresh about:support contents with EGL enabled.

Here is a fresh profile with EGL enabled.

(In reply to andysem from comment #11)

The referenced bug cites enabling EGL as the solution/workaround, and it does not help in my case.

When starting Firefox 92 with MOZ_X11_EGL=1:
Do you encounter the same problem when playing the video in a second regular window instead of a PiP window?

(In reply to Darkspirit from comment #15)

(In reply to andysem from comment #11)

The referenced bug cites enabling EGL as the solution/workaround, and it does not help in my case.

When starting Firefox 92 with MOZ_X11_EGL=1:
Do you encounter the same problem when playing the video in a second regular window instead of a PiP window?

Yes, the issue reproduces with the second window as well, exactly like with PiP.

The page with the video (Youtube) in the new window scrolls smoothly. The original window from which the video was forked scrolls with noticeably reduced frame rate. I can switch to different tabs in the original window - the scrolling frame rate is consistently low on every tab. Even the list of tabs, as I scroll through it with the mouse wheel, is animated at reduced frame rate.

Is it also reproducible with https://nightly.mozilla.org?

I've recorded a screencast of this issue. On the left is the original window, on the right is the window with the video. You can see the scrolling on the left becomes noticeably choppy when the video on the right starts playing.

(In reply to Darkspirit from comment #17)

Is it also reproducible with https://nightly.mozilla.org?

Yes, it is.

(In reply to andysem from comment #19)

(In reply to Darkspirit from comment #17)

Is it also reproducible with https://nightly.mozilla.org?

Yes, it is.

Forgot to mention that the tested build id is 20210921094642.

Also, in the recorded screencast the issue is not as pronounced as in real use. I had to make the windows smaller to avoid the video encoder from saturating the CPU. In the real life the browser is maximized on a 4K display, and scrolling while the video is playing appears more choppy.

(In reply to andysem from comment #20)

Forgot to mention that the tested build id is 20210921094642.

Can you still reproduce this if you set layout.frame_rate = 0 and restart Nightly?

(In reply to Darkspirit from comment #21)

Can you still reproduce this if you set layout.frame_rate = 0 and restart Nightly?

Yes, it still reproduces.

Thanks! Then you have found a new bug. (bug 1631353 comment 16 could also be relevant.)

Can you still reproduce this if you set gfx.webrender.allow-partial-present-buffer-age to false, gfx.webrender.max-partial-present-rects to 0 and restart Nightly? Or does it even become worse?

(In reply to Darkspirit from comment #23)

Can you still reproduce this if you set gfx.webrender.allow-partial-present-buffer-age to false, gfx.webrender.max-partial-present-rects to 0 and restart Nightly? Or does it even become worse?

Yes, it still reproduces. The properties make no difference.

(In reply to andysem from comment #22)

(In reply to Darkspirit from comment #21)

Can you still reproduce this if you set layout.frame_rate = 0 and restart Nightly?

Yes, it still reproduces.

An update. Previously, I tested this property with EGL enabled, and the issue indeed reproduced.

Today I tried this property with EGL force-disabled, and the scrolling issue did not reproduce. However, instead my 4-core CPU is constantly loaded for about 45-50% on all cores (where 100% would mean all cores saturated) while the video is playing - in PiP mode or not. Normally, playing the same video consumes around 15-20% CPU.

Also, I tested gfx.webrender.allow-partial-present-buffer-age and gfx.webrender.max-partial-present-rects with EGL enabled as well.

Can you still reproduce this bug if you start Nightly with __GL_MaxFramesAllowed=1 environment variable?
$ __GL_MaxFramesAllowed=1 ./firefox
Please try with EGL (default) and with gfx.x11-egl.force-disabled=true (Firefox restart required to apply pref change).

Does __GL_SYNC_TO_VBLANK=0 help?

(In reply to Darkspirit from comment #26)

Can you still reproduce this bug if you start Nightly with __GL_MaxFramesAllowed=1 environment variable?
$ __GL_MaxFramesAllowed=1 ./firefox
Please try with EGL (default) and with gfx.x11-egl.force-disabled=true (Firefox restart required to apply pref change).

__GL_MaxFramesAllowed=1 has no effect, with or without EGL.

Does __GL_SYNC_TO_VBLANK=0 help?

__GL_SYNC_TO_VBLANK=0 has no effect without EGL. With EGL, it seems partially better, but not completely fixed. It looks like the browser randomly alternates between the normal and reduced frame rates when scrolling, which appears as jittery animation. Sometimes it may look like normal for several seconds but then, presumably after a random CPU spike, the frame rate may drop.

https://download.nvidia.com/XFree86/Linux-x86_64/410.66/README/openglenvvariables.html

By default, the driver calls sched_yield() to do this. However, this can cause the calling process to be scheduled out for a relatively long period of time if there are other, same-priority processes competing for time on the CPU. One example of this is when an OpenGL-based composite manager is moving and repainting a window and the X server is trying to update the window as it moves, which are both CPU-intensive operations.

Does one of these environment variables make a difference?
__GL_YIELD="NOTHING"

__GL_YIELD="USLEEP"

(In reply to Darkspirit from comment #28)

Does one of these environment variables make a difference?
__GL_YIELD="NOTHING"

__GL_YIELD="USLEEP"

__GL_YIELD="USLEEP" is set globally on my system, all previous testing was done with it.

Unsetting __GL_YIELD has no effect. Setting it to nothing does not fix the scrolling (it is consistently bad), but considerably increases CPU consumption. Both with and without EGL.

I also tried setting __GL_SYNC_DISPLAY_DEVICE to the display on which FF was opened, it had no effect.

(In reply to andysem from comment #29)

(In reply to Darkspirit from comment #28)

Does one of these environment variables make a difference?
__GL_YIELD="NOTHING"

__GL_YIELD="USLEEP"

__GL_YIELD="USLEEP" is set globally on my system, all previous testing was done with it.

Unsetting __GL_YIELD has no effect. Setting it to nothing

I mean "NOTHING", all caps.

does not fix the scrolling (it is consistently bad), but considerably increases CPU consumption. Both with and without EGL.

I also tried setting __GL_SYNC_DISPLAY_DEVICE to the display on which FF was opened, it had no effect.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: