Closed Bug 1646786 Opened 4 years ago Closed 4 years ago

Video Stutters on a 4k Monitor at 150% Zoom level

Categories

(Core :: Graphics: WebRender, defect)

Desktop
Windows 10
defect

Tracking

()

VERIFIED FIXED
81 Branch
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- disabled
firefox77 --- disabled
firefox78 --- wontfix
firefox79 --- wontfix
firefox80 --- wontfix
firefox81 --- verified
firefox82 --- verified

People

(Reporter: rdoghi, Assigned: mattwoodrow)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

[Affected versions]:
Beta 78.0b8
Nightly 79.0a1 (2020-06-18)

[Affected platforms]:
Platforms: Windows 10

Steps :

  1. Launch the Firefox browser and set the Global zoom from about:preferences to 150%.
  2. Reach https://www.walmart.com/cp/video-games/2636 and scroll down to the Xbox v PS5 videos.
  3. Click the PS5 play button in order to play the video.
  4. Click the Full screen button.
  5. Around the 1:20 mark start moving the mouse in order for the seek bar to be displayed.
  6. Keep moving the mouse while the video is playing.

Expected Results :
The video playback should be smooth and without any stutters.

Actual Results :
The video plays with stutters for as long as the user keeps moving the mouse cursor.

Please note that this issue only occurs on (3840 x 2160) resolution.
This issue does not occur on smaller resolutions like (2560 x 2048).
Even on High resolution this issue is only noticeable with WebRender on.
This issue does not occur when the Global Zoom level is set to the default 100%.

Attached file aboutSUpport620.txt (deleted) —

I have attached the about support info to this bug

Is this a regression?

Flags: needinfo?(rares.doghi)
Severity: -- → S3
Blocks: wr-79
No longer blocks: gfx-triage
Severity: S3 → --
Flags: needinfo?(rares.doghi)
Keywords: regression
Regressed by: 1592509
Has Regression Range: --- → yes
Blocks: wr-80
No longer blocks: wr-79
Severity: -- → S3

Glenn can you take a look to see if you can repro?

Flags: needinfo?(gwatson)

I haven't been able to reproduce with a local build on that hardware yet.

Would it be possible to provide some screenshots when it is stuttering with the following about:config settings enabled:

gfx.webrender.debug.gpu-time-queries, gfx.webrender.debug.profiler and gfx.webrender.debug.picture-caching

You shouldn't need to restart the browser after changing those settings, but a couple of screenshots with those settings enabled around when the stuttering occurs may offer some clues as to what is happening.

Flags: needinfo?(gwatson) → needinfo?(rares.doghi)
Attached image Stutter4K.png (deleted) —

Attaching the screenshot for when it stutters.

Flags: needinfo?(rares.doghi)

This is very helpful, thanks!

The most notable things from that screenshot:

  • The tile layout looks about what I would expect - tiles surrounding the UI overlay, but not where the video is (as it's a compositor surface).
  • The GPU time is spiking above 16ms regularly, but is not constantly struggling every frame.
  • The most apparent problem is in CPU time inside the Renderer thread - lots of red spikes, peaking at 100ms.

So this suggests we're seeing some kind of stall in the CPU render thread / driver, or perhaps some kind of stall inside a DirectComposition API call.

The next step, if possible, is to get a Firefox profile [1] and share a link here for further inspection. If you're able to do that, please ensure that the screenshots option is disabled, as that drastically affects the profile of graphics related things.

[1] https://profiler.firefox.com/

Hi Glenn, I used the Media option from the profile cause I noticed that one does not have the screenshot option checked and got these results : https://share.firefox.dev/3j8vHVs please note that the stutters were less noticeable in our latest nightly build but still there.

Also if you have a Custom option for the profiler that would help more with this issue let me know and ill try this again.

Flags: needinfo?(gwatson)
Flags: needinfo?(gwatson) → needinfo?(sotaro.ikeda.g)

Hmm - I wonder if under this zoom scenario the 4k external image results in a very large DC surface being allocated due to the zoom factor? (I wouldn't expect so, but that might explain what's happening if the issues are actually GPU time problems).

No longer blocks: wr-80
Blocks: wr-81

@Rares: can you see if this still occurs in nightly?

Flags: needinfo?(rares.doghi)

Hi Kris , we dont currently have access to that laptop since it was loaned to us just for that Webrender on Intel laptops with a 4k resolution feature and I'm also on PTO for the next week but we will try to get our hands on that device as soon as possible and let you know.

No longer blocks: wr-81

Hi Kris, I got my hands on the laptop in question and I tested our Latest Nightly build and the issue no longer occurs there, I did notice a stutter from time to time but nothing to noticeable.. where in Beta 81 it stutters constantly.

Flags: needinfo?(rares.doghi) → needinfo?(ktaeleman)

(In reply to Glenn Watson [:gw] from comment #9)

It seems like we are seeing some very long stalls inside NtGdiDdDDIWaitForSynchronizationObjectFromCpu [1].

Sotaro, do you have any ideas what might cause this? Do you have hardware that you may be able to reproduce this case on?

It seemed to mean GPU task was heavy. But from comment 13, gpu task might be reduced on nightly.

Flags: needinfo?(sotaro.ikeda.g)

Rares can you try to find what fixed this in nightly (mozregression --find-fix)? Would be good to understand what changed.

Flags: needinfo?(rares.doghi)
Flags: needinfo?(ktaeleman)

Bug 1653166 might have helped.

Hi I tried to Find the commit that improved this but this is as close as I could get :

First known good

app_name: firefox
build_date: 2020-08-04 10:49:07.402000
build_file: C:\Users\svuser.mozilla\mozregression\persist\7cb90fa4f485--mozilla-central--target.zip
build_type: integration
build_url: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/CYrOeVNDTeqFTbvzkZ5d8w/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
changeset: 7cb90fa4f485fc9dda5c1fef3ae09a826f83774a
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=255b4f5888e9e9cdd40f59fec969af247859d76a&tochange=7cb90fa4f485fc9dda5c1fef3ae09a826f83774a
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central
task_id: CYrOeVNDTeqFTbvzkZ5d8w

It does seem like Bug 1653166 is the one that improved video playback.

Flags: needinfo?(rares.doghi)
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Assignee: nobody → matt.woodrow
Depends on: 1653166
Target Milestone: --- → 81 Branch

This issue is Verified as fixed in our latest Release version 82.0.1 on Windows 10.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: