Lots of flickering on latest Nightly on https://www.humblebundle.com/games/builder-bundle
Categories
(Core :: Graphics: WebRender, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox70 | --- | unaffected |
firefox71 | --- | verified |
People
(Reporter: Yoric, Assigned: aosmond)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files)
Tried on https://www.humblebundle.com/games/builder-bundle . Pretty much everything flickers. See attachment.
Comment 1•5 years ago
|
||
Reproducible with webrender but not without for me.
Comment 2•5 years ago
|
||
regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a8b8823a6b72114f4150fbcd2ab0728b833b6a04&tochange=ef5f9e04f04b648bdee5517bcbf71895acf2314e
-> bug 1574493
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
Reduced test case. If I toggle picture caching off, the problem goes away. Glenn, do you think this is a latent bug with picture caching, or is there something obvious in my patches that interferes with it to you?
Assignee | ||
Comment 4•5 years ago
|
||
Also worth noting is that if I remove the text-shadow from the "Humble Builder Bundle" text, the wrong background flickering goes away.
Assignee | ||
Comment 5•5 years ago
|
||
I thought this might be relevant in P2, but it appears restoring it to always invalidate the segments and GPU cache handles did nothing. It shouldn't need it anymore since the local rect is always the same now (we can probably remove the segments invalidated flag too now?).
Assignee | ||
Updated•5 years ago
|
Comment 6•5 years ago
|
||
I suspect this might be fixed by https://phabricator.services.mozilla.com/D46247 when it lands. I'll take a closer look this morning.
Comment 7•5 years ago
|
||
That patch doesn't fix the problem. I also checked and the flickering doesn't seem to be where any of the tile boundaries are.
Comment 8•5 years ago
|
||
Hmm, I see the bug even with picture caching completely disabled here, so it seems likely that it's something in the snapping patches that mozregression pointed to.
Comment 9•5 years ago
|
||
If I bisected correctly, this is the commit that caused or exposed the issue:
a6418af845752ba659bd7a88333b9f80fea98745 is the first bad commit
commit a6418af845752ba659bd7a88333b9f80fea98745
Author: Andrew Osmond <aosmond@mozilla.com>
Date: Sat Sep 14 16:17:02 2019 +0000
Bug 1574493 - Part 2. Remove snapping in frame building. r=kvark
This will be rewritten in a later patch in the series. The shaders will
be provided the correct information and will no longer need to concern
themselves with snapping.
I'll take a closer look at this commit and see if I can spot anything odd.
Comment 10•5 years ago
|
||
I'm possibly just misunderstanding that patch, but it looks like the code that propagates the local rect of pictures up to the parent surface was removed, and I don't see anything that replaces it? Perhaps it's related to that? That would definitely be affected by things like text shadows, which create a picture that dynamically calculate the bounding rect?
Comment 11•5 years ago
|
||
If that is the issue, it looks like you might be able to fix it by adding pictures to the list of deferred prim items that have their bounding rects handled later, in the same way as backdrop filter prims?
Assignee | ||
Comment 12•5 years ago
|
||
Glenn, been working through the code changes this morning, and I think I understand what you mean now in comment 10. I think you are correct, the pictures aren't included in the calculations on the first pass. Or at least not in their entirety. It used to work this way, and I thought I was just restoring the old behaviour, but maybe it was always wrong :).
Assignee | ||
Comment 13•5 years ago
|
||
As it turns out, the difference between the snapped local rect and the
unsnapped local rect was not just that the former contained snapped
primitives and the latter contained unsnapped primitives, but also that
the former took into account surface inflation for primitives, the
entire clip chain instead of just the primitive's local clip, and
removal of culled primitives. As such, the picture's rects can be wildly
different, even if snapping has been taken care of earlier, and parts of
WebRender have come to rely upon this more accurate representation of a
picture.
Comment 14•5 years ago
|
||
Comment 15•5 years ago
|
||
Backed out changeset 56c82d00c513 (Bug 1581934) for reftest failures CLOSED TREE
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=268037959&repo=autoland&lineNumber=4147
Backout: https://hg.mozilla.org/integration/autoland/rev/b62a3a29d3ace5654ce7acc9f940fa323f7946d3
Comment 16•5 years ago
|
||
Comment 17•5 years ago
|
||
Comment 18•5 years ago
•
|
||
Backed out changeset 43dbcbd6f57a (bug 1581934) for causing reftest failures on 1081185-1.html
Backout revision https://hg.mozilla.org/integration/autoland/rev/6a1f7dcb1266d47857db1895ca9cc12ca9eeff45
Failure logs https://treeherder.mozilla.org/logviewer.html#?job_id=268088639&repo=autoland
https://treeherder.mozilla.org/logviewer.html#?job_id=268090600&repo=autoland
Andrew can you please take another look?
Comment 19•5 years ago
|
||
Assignee | ||
Updated•5 years ago
|
Comment 21•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Reporter | ||
Comment 24•5 years ago
|
||
Confirmed (assuming that humblebundle.com didn't change their code): I don't see the issue on humblebundle.com anymore.
Updated•5 years ago
|
Comment 25•5 years ago
|
||
Hello! Reproduced the issue using Firefox 71.0a1 (20190916155843) on Windows 10x64. and the test case provided in comment 3.
The issue is verified fixed with Firefox 71.0b9 (20191111170815) on Windows 10x64, Ubuntu 18.04 and macOS 10.12. No flicker showed on the test case while using Webrender.
Description
•