1559284 - WebRender picture caching implementation results in extremely choppy YouTube videos unless the mouse cursor is actively over the viewport.

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect, P2)

Description

[Ross McCluskie]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

Latest Nightly build. WebRender in use.

Open any YouTube video - preferebably of reasonable quality.

Note when the cursor is over the video viewport the playback will be as expected.

When you remove the cursor from the viewport it will immediately become very choppy and stuttery. Stats for Nerds shows no dropped frames.

Confirmed to be in relation to 1558106 as when gfx.webrender.picture-caching is set to false the issue is resolved.

Actual results:

Moving the cursor away from the video viewport results in massive reduction in video playback performance.

Expected results:

Video would playback as expected. Expected results can be reproduced by setting gfx.webrender.picture-caching to false (and restarting Firefox).

Comment 1

[Glenn Watson [:gw]]

This sounds like it might be related to the code that checks if a tile can be cached at all (cache tiles get disabled when there is content that contains a video). I don't see anything immediately obvious in the patch above that would have changed how that is handled. I'll do a local build now and see I can reproduce here locally.

Comment 2

[Glenn Watson [:gw]]

This reproduces on a Windows build, but not on a Linux build. Doing local builds of both now to see what the difference is.

Comment 3

[Sotaro Ikeda [:sotaro]]

I wonder if the problem might happen when only update is an update of WebRenderTextureHostWrapper. In this case, native texture is updated outside of WR. In this case, aMaybeFastTxn.InvalidateRenderedFrame() forces frame rendering in next generate frame. update_document() make sure WR frame rendering by "doc.rendered_frame_is_valid".

https://dxr.mozilla.org/mozilla-central/source/gfx/layers/wr/AsyncImagePipelineManager.cpp#321
https://dxr.mozilla.org/mozilla-central/source/gfx/wr/webrender/src/render_backend.rs#1446

Comment 4

[Glenn Watson [:gw]]

Yes, I think it will be related to this. The picture caching code does have a special case to avoid caching when it encounters a tile that has a native / external image affecting it though. This check should be applying here, but I suspect it's not working.

Comment 5

[Glenn Watson [:gw]]

Oh wait, I see what you mean - it completely skips the frame build altogether in this case, right? Hmm, yes, that's going to break with picture caching if I understand that code fragment correctly...

Comment 6

[Glenn Watson [:gw]]

Sotaro is exactly right about the cause of this. The optimization above means the picture caching code doesn't run, which means we end up with stale tiles. Sotaro will temporarily disable this optimization for now, as a quick fix, and we will work out a better long term fix.

Comment 7

[bl.lebrun]

This issue is also happening with Twitter videos as well. Cursor over the video doesn't fix the issue like YouTube however

Comment 8

[Sotaro Ikeda [:sotaro]]

Created Bug 1559294, for re-enable fast path for async native texture updates

Comment 9

[Sotaro Ikeda [:sotaro]]

Attachment: Bug 1559284 - Disable fast path for async native texture updates

Comment 10

[Sotaro Ikeda [:sotaro]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d32c06dcef63b433c50d5867cfd1aacd3eae6b73

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/37cdc2b89e3c
Disable fast path for async native texture updates r=gw

Comment 14

[gixxpunk]

Looks like this fix is only aimed towards Webrender. I checked with Webrender disabled and the YT videos are also bugged for me with 20190613 NIGHTLY.

Comment 15

[Darkspirit]

(In reply to gixxpunk from comment #14)

Looks like this fix is only aimed towards Webrender. I checked with Webrender disabled and the YT videos are also bugged for me with 20190613 NIGHTLY.

Please open about:support and check the value of "Compositing". If it's not "WebRender", please file a new bug. Thanks!

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Tracking this for 69 for now as WR is still mostly opt-in. I'll bump this to blocker status if it turns out to affect non-WR also.

Comment 19

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/37cdc2b89e3c

Comment 29

[Alexandru Trif, Desktop QA [:atrif]]

Hello!
Successfully reproduced the issue using Firefox 69.0a1 (20190613215335) on Windows 10x64.
The issue is verified fixed with Firefox 69.0b6 (20190718172058) on Windows 10x64.