Closed Bug 1670793 Opened 4 years ago Closed 4 years ago

sw-wr: animated GIF has white rectangles that flash or aren't painted

Categories

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

defect

Tracking

()

RESOLVED FIXED
83 Branch
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

  1. Enable gfx.webrender.software = true and restart Nightly.
  2. Open this animated GIF attached in bug 1670263: https://bug1670263.bmoattachments.org/attachment.cgi?id=9180702
  3. 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.

After maximizing Nightly (2560x1440 display) and zooming in to 270% I was able to repro this on Linux.

Has STR: --- → yes
Component: General → Graphics: WebRender
Keywords: correctness
OS: Unspecified → All
Hardware: Unspecified → All

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 :)

(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.

No longer regressed by: 1666119, 1667919

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

Has Regression Range: --- → yes
Keywords: regression
Regressed by: 1652894

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?

Flags: needinfo?(sotaro.ikeda.g)

(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

Flags: needinfo?(sotaro.ikeda.g)
Assignee: nobody → matt.woodrow
No longer blocks: gfx-triage
Pushed by mwoodrow@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a6d117305fe6 Hold animated shared surface until the end of the composite when using software GL. r=sotaro
Severity: -- → S3
Priority: -- → P3
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch

Could this have caused bug 1673906?

Flags: needinfo?(matt.woodrow)
Flags: needinfo?(matt.woodrow)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: