Closed Bug 1448896 Opened 2 years ago Closed 2 years ago


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




Tracking Status
firefox-esr52 --- unaffected
firefox59 --- unaffected
firefox60 --- unaffected
firefox61 --- unaffected


(Reporter: mayankleoboy1, Assigned: sotaro)


(Blocks 1 open bug, )


(Keywords: nightly-community)


(2 files, 1 obsolete file)

Attached 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

Actual results:

page flicker

Expected results:

not so
Reproduces for me on Dell XPS with Nvidia card.
Assignee: nobody → kvark
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
Ever confirmed: true
See Also: → 1445034
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 startup.homepage_welcome_url:""

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 startup.homepage_welcome_url:""

skia-gl: flickering
See Also: → 1438301
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.
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
Flags: needinfo?(sotaro.ikeda.g)
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)
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.
attachment 8967284 [details] [diff] [review] addressed the problem for me.
Relaxed assert.
Attachment #8967284 - Attachment is obsolete: true
Attachment #8967297 - Flags: review?(nical.bugzilla)
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:""
mozregression --launch 2018-04-11 --pref gfx.webrender.all:true startup.homepage_welcome_url:""
-> bad like in comment 3

mozregression --repo try --launch 1968797a8ca3f3526efd7be71c222c53ec5e92bc --pref gfx.webrender.all:true startup.homepage_welcome_url:""
mozregression --repo try --launch 1968797a8ca3f3526efd7be71c222c53ec5e92bc --pref gfx.webrender.all:true startup.homepage_welcome_url:""
-> fixed

Thank you!
Pushed by
Change some messages to WebRenderParentCommand r=nical
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
You need to log in before you can comment on or make changes to this bug.