1448896 - https://lab.hakim.se/linjer/#diagonal flickers with WR

Status: RESOLVED FIXED

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

Description

[Mayank Bansal]

Attachment: aboutsupport.txt

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180325220121

Steps to reproduce:

1. Create new profile on nightly win10x64 intel iGPU
2. enable WR. Restart
3. Go to https://lab.hakim.se/linjer/#diagonal


Actual results:

page flicker


Expected results:

not so

Comment 1

[Milan Sreckovic [:milan] (needinfo for best results)]

Reproduces for me on Dell XPS with Nvidia card.

Comment 2

[Dzmitry Malyshau [:kvark]]

I looked at it on our reference machine. Preliminary conclusion is that it's the same problem with 2D transforms/scrolling Nicola has been looking into, and it is addressed in https://github.com/servo/webrender/pull/2568

Comment 3

[Darkspirit]

Debian Testing (KDE, Radeon RX480)

latest try build from bug 1447998 comment 5 (same results with the current Nightly):
> mozregression --repo try --launch a92e61fbb71b3b6e9825e5bb15e58fd9887fb40f --pref gfx.webrender.all:true gfx.canvas.azure.accelerated:false startup.homepage_welcome_url:"https://lab.hakim.se/linjer/#diagonal"

sometimes, e.g. after tab switching or hovering some tabs, it's dark for some milliseconds (does not happen with a non-WR Nightly)

> mozregression --repo try --launch a92e61fbb71b3b6e9825e5bb15e58fd9887fb40f --pref gfx.webrender.all:true gfx.canvas.azure.accelerated:true startup.homepage_welcome_url:"https://lab.hakim.se/linjer/#diagonal"

skia-gl: flickering

Comment 4

[Dzmitry Malyshau [:kvark]]

Jan, thanks for the heads up! I'm going to look at it at greater depth then, since it's not addressed by the segment clips PR.

Comment 5

[Dzmitry Malyshau [:kvark]]

I'm getting interesting results so far:
Linux - no issues
Windows (any HW) - occasional flickering
OSX - crash

Comment 6

[Dzmitry Malyshau [:kvark]]

I've been looking at the issue lately. It's not OS dependent, it's timing-sensitive.
Sometimes, Gecko sends WR a scene with main display list using a pipeline (for an external texture) that has not been provided. Currently, WR ignores that silently (and I'll fix this). Sprinkling the logging over WR bridge parent, it looks like we always follow-up with that dependent DL (via `ApplyAsyncImages`) after the main frame is sent. So what may happen is - some circumstances forcing WR to display a frame in the moment between those DLs arriving.

Comment 7

[Dzmitry Malyshau [:kvark]]

Sotaro, this seems to be your area of expertise.

Here is a rehash of what happens:
  1. the user has a canvas, which gets reset it's width/height each frame. This forces us to re-create the canvas as well as the associated WR pipeline for it.
  2. when we fill up the main transaction (containing our root pipeline/display list), we remove the old pipeline associated with the canvas (in WebRenderBridgeChild::RemovePipelineIdForCompositable), create a new one, and have an iframe item associated with this new pipeline (in nsDisplayCanvas::CreateWebRenderCommands).
  3. no display list for that new pipeline is provided as a part of the main transaction. When WR receives it and builds it, it fails to find the associated DL and ignores the iframe item. If, for some reason, it decides to refresh the frame (say, due to a scrolling event), the canvas is not being rendered, thus the flash occurs (this bug!).
  4. the new DL is provided (in AsyncImagePipelineManager::ApplyAsyncImages) later on by Gecko

Roughly, I could see two possible ways to approach this:

A: move the new DL construction earlier, to be a part of the main transaction
B: hold on to the old pipeline until the new DL is provided

Both are non-trivial, and would take me quite a bit of time to test. Perhaps, you could see better.

Comment 8

[Sotaro Ikeda [:sotaro]]

Thanks for the detailed investigation! I could reproduce the problem on win10. I take a look.

Comment 9

[Sotaro Ikeda [:sotaro]]

Some messages that related to async image pipeline and external image are sent as independent messages to WebRenderBridgeParent. It seems better that the messages are sent as part of transaction as WebRenderParentCommands.

Comment 10

[Sotaro Ikeda [:sotaro]]

Attachment: patch - Change some messages to WebRenderParentCommand

Comment 11

[Sotaro Ikeda [:sotaro]]

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

Comment 12

[Sotaro Ikeda [:sotaro]]

attachment 8967284 [details] [diff] [review] addressed the problem for me.

Comment 13

[Sotaro Ikeda [:sotaro]]

Attachment: patch - Change some messages to WebRenderParentCommand

Relaxed assert.

Comment 14

[Sotaro Ikeda [:sotaro]]

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

Comment 15

[Darkspirit]

Debian Testing, Radeon RX480

mozregression --launch 2018-04-11 --pref gfx.webrender.all:true startup.homepage_welcome_url:"https://lab.hakim.se/linjer/#diagonal"
mozregression --launch 2018-04-11 --pref gfx.webrender.all:true gfx.canvas.azure.accelerated:true startup.homepage_welcome_url:"https://lab.hakim.se/linjer/#diagonal"
-> bad like in comment 3

mozregression --repo try --launch 1968797a8ca3f3526efd7be71c222c53ec5e92bc --pref gfx.webrender.all:true startup.homepage_welcome_url:"https://lab.hakim.se/linjer/#diagonal"
mozregression --repo try --launch 1968797a8ca3f3526efd7be71c222c53ec5e92bc --pref gfx.webrender.all:true gfx.canvas.azure.accelerated:true startup.homepage_welcome_url:"https://lab.hakim.se/linjer/#diagonal"
-> fixed

Thank you!

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/810a838ce26e
Change some messages to WebRenderParentCommand r=nical

Comment 17

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/810a838ce26e