sw-wr: animated GIF has white rectangles that flash or aren't painted
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox81 | --- | disabled |
firefox82 | --- | disabled |
firefox83 | --- | disabled |
People
(Reporter: cpeterson, Assigned: mattwoodrow)
References
(Blocks 1 open bug, Regression, )
Details
(Keywords: correctness, regression)
Attachments
(2 files)
Steps to reproduce
- Enable gfx.webrender.software = true and restart Nightly.
- Open this animated GIF attached in bug 1670263: https://bug1670263.bmoattachments.org/attachment.cgi?id=9180702
- Watch the animation.
Expected result
The animation should paint all the pixels.
Actual result
The animation has some white rectangles that flash or don't get painted. See the attached screenshot.
I am running Nightly 83.0a1 (2020-10-12) on Windows 10.
Reporter | ||
Comment 1•4 years ago
|
||
This bug is probably a regression from Composite crash bug 1666119 or gGetGraphicsResetStatus crash bug 1667919. I bisected this bug to this pushlog:
Comment 2•4 years ago
|
||
After maximizing Nightly (2560x1440 display) and zooming in to 270% I was able to repro this on Linux.
Assignee | ||
Comment 3•4 years ago
|
||
Are you sure you're getting software webrender before that regression range?
I can still repro with those patches backed out, so it's possible that you're just crashing the GPU process before that and not seeing the bug :)
Reporter | ||
Comment 4•4 years ago
|
||
(In reply to Matt Woodrow (:mattwoodrow) from comment #3)
Are you sure you're getting software webrender before that regression range?
I can still repro with those patches backed out, so it's possible that you're just crashing the GPU process before that and not seeing the bug :)
Looks like you're correct. I see in the good builds' about:support
"Compositing" is "Basic", not "WebRender (Software)". Since this bug is not necessarily a regression, I will unlink those "Regressed by" bugs.
Comment 5•4 years ago
|
||
Gnome X11, Mesa/Nouveau, Debian Testing
Maximize, zoom in.
mozregression --good 2020-04-15 --bad 2020-08-15 --pref gfx.webrender.all:true gfx.webrender.software:true -a https://bug1670263.bmoattachments.org/attachment.cgi?id=9180702
12:23.75 INFO: Last good revision: a0ed52a4de5ece14a3032d2a0af69576acda7cdd
12:23.75 INFO: First bad revision: 46acaaf0f72398fc584ee81ff90a8d39b525bdfa
12:23.75 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a0ed52a4de5ece14a3032d2a0af69576acda7cdd&tochange=46acaaf0f72398fc584ee81ff90a8d39b525bdfa
fdda2e1419dd99d75d961e1a9c5d40f0507adf20 Lee Salzman — Bug 1652894 - add SWGL RenderTextureHosts. r=mattwoodrow
08a8b2422765ec7d46577a76cb873f3f738fb421 Lee Salzman — Bug 1652894 - fix SWGL code formatting. r=mattwoodrow
108cb2f4c72cef66c928b2e31a5e2eede6dd7fee Lee Salzman — Bug 1652894 - add SWGL utility bindings for managing textures. r=jimb
422ffc69f0c90208471fca31137319ec70082162 Lee Salzman — Bug 1652894 - allow SWGL contexts to have multiple strong references. r=jimb
Assignee | ||
Comment 6•4 years ago
|
||
This breaks because WebRenderBridgeParent::UpdateResources assumes that we always copy shared external textures into the texture cache, and notifies the content process that it can recycle the associated memory - https://searchfox.org/mozilla-central/rev/d25eb00ab4e90cc0130cd18f303a04cc2a2f8409/gfx/layers/wr/WebRenderBridgeParent.cpp#642
With SWGL however, we render directly from shared surfaces - https://searchfox.org/mozilla-central/rev/d25eb00ab4e90cc0130cd18f303a04cc2a2f8409/gfx/layers/wr/WebRenderBridgeParent.cpp#708
Writing to the shared memory for a different animation frame while SWGL is reading from it to composite causes the flashing.
We need to delay notifying that the textures are free until we no longer have a display list referencing them, or go back to copying these surfaces into the texture cache. The former seems like it'd perform better, but maybe it's not a big deal.
Sotaro, do you have any ideas how we could delay freeing these surfaces until we will no longer be drawing from them?
Comment 7•4 years ago
•
|
||
(In reply to Matt Woodrow (:mattwoodrow) from comment #6)
Sotaro, do you have any ideas how we could delay freeing these surfaces until we will no longer be drawing from them?
I wonder if ScheduleSharedSurfaceRelease caused the problem. It triggers WebRenderBridgeParent::ObserveSharedSurfaceRelease() at wr::Checkpoint::FrameTexturesUpdated. And it releases SharedSurfaces.
https://searchfox.org/mozilla-central/rev/d25eb00ab4e90cc0130cd18f303a04cc2a2f8409/gfx/layers/wr/WebRenderBridgeParent.cpp#814
https://searchfox.org/mozilla-central/rev/d25eb00ab4e90cc0130cd18f303a04cc2a2f8409/gfx/layers/wr/WebRenderBridgeParent.cpp#642
https://searchfox.org/mozilla-central/rev/d25eb00ab4e90cc0130cd18f303a04cc2a2f8409/gfx/layers/wr/WebRenderBridgeParent.cpp#832
With sw-wr, it seems better to use AsyncImagePipelineManager::HoldExternalImage() as it is called from WebRenderBridgeParent::ReleaseTextureOfImage(). SharedSurface is actually released by ForwardingExternalImage::~ForwardingExternalImage()
Though, name of HoldExternalImage() is confusing now. It hold the external image until a specified epoch and release it when epoch is exceeded.
https://searchfox.org/mozilla-central/source/gfx/layers/wr/WebRenderBridgeParent.cpp#1709
https://searchfox.org/mozilla-central/rev/d25eb00ab4e90cc0130cd18f303a04cc2a2f8409/gfx/layers/wr/AsyncImagePipelineManager.cpp#30
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 8•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 10•4 years ago
|
||
bugherder |
Assignee | ||
Updated•4 years ago
|
Description
•