RESOLVED FIXED in mozilla61

Status

()

P1
normal
RESOLVED FIXED
a year ago
11 months ago

People

(Reporter: mayankleoboy1, Assigned: sotaro)

Tracking

(Blocks: 1 bug, {nightly-community})

Trunk
mozilla61
Unspecified
All
nightly-community
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox59 unaffected, firefox60 unaffected, firefox61 unaffected)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

a year ago
Posted file 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
Reproduces for me on Dell XPS with Nvidia card.
Assignee: nobody → kvark
Blocks: 1386665
Priority: -- → P1
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
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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
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.
Blocks: 1423269
status-firefox59: --- → unaffected
status-firefox60: --- → unaffected
status-firefox61: --- → unaffected
status-firefox-esr52: --- → unaffected
Keywords: nightly-community
OS: Unspecified → All
I'm getting interesting results so far:
Linux - no issues
Windows (any HW) - occasional flickering
OSX - crash
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.
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.
Assignee: kvark → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(sotaro.ikeda.g)
(Assignee)

Comment 8

11 months ago
Thanks for the detailed investigation! I could reproduce the problem on win10. I take a look.
Assignee: nobody → sotaro.ikeda.g
Flags: needinfo?(sotaro.ikeda.g)
(Assignee)

Comment 9

11 months ago
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.
(Assignee)

Comment 12

11 months ago
attachment 8967284 [details] [diff] [review] addressed the problem for me.
(Assignee)

Comment 13

11 months ago
Relaxed assert.
Attachment #8967284 - Attachment is obsolete: true
(Assignee)

Updated

11 months ago
Attachment #8967297 - Flags: review?(nical.bugzilla)

Updated

11 months ago
Attachment #8967297 - Flags: review?(nical.bugzilla) → review+
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

11 months ago
Pushed by sikeda@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/810a838ce26e
Change some messages to WebRenderParentCommand r=nical
https://hg.mozilla.org/mozilla-central/rev/810a838ce26e
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Blocks: 1454042
You need to log in before you can comment on or make changes to this bug.