Closed Bug 1686800 Opened 4 years ago Closed 4 years ago

Black flash software webrender (d3d11 compositor) on Windows 10

Categories

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

Product:
Core
Component:
Graphics: WebRender
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
88 Branch
Tracking Flags:
Tracking Status
firefox88 --- fixed

People

(Reporter: jrmuizel, Assigned: sotaro)

References

(Blocks 2 open bugs)

Details

Attachments

(2 files)

temporal patch - Clear with red
(deleted), patch
Details | Diff | Splinter Review
Bug 1686800 - Call mCompositor->EndFrame() only when StartCompositing() is called
(deleted), text/x-phabricator-request
Details

With software webrender enabled I get a black flash in-between the skeleton UI showing up and the real UI showing up.

Blocks: 1665451
Summary: Blank flash with SkeletonUI and software webrender on Windows 10 → Black flash with SkeletonUI and software webrender on Windows 10

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: General → Graphics: WebRender
Product: Firefox → Core
Severity: -- → S4
Priority: -- → P3

This happens without the skeleton UI. The skeleton UI just makes it more noticeable.

Summary: Black flash with SkeletonUI and software webrender on Windows 10 → Black flash software webrender (d3d11 compositor) on Windows 10

To summarize:
HW-WR: no flash
SW-WR-d3d11: black flash
d3d11: no flash
SW-WR: no flash

Sotaro or Matt any guesses as to the cause here?

Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(matt.woodrow)
Attached patch temporal patch - Clear with red (deleted) — — Splinter Review

With the patch, Firefox had red flash. From it, no rendering seems to cause the black flash.

Is this because RenderCompositorLayersSWGL calls BeginFrameForWindow, which includes a clear?

RenderCompositorSWGL only clears the buffer from StartCompositing/AllocateMappedBuffer.

If there's a frame where gecko calls RenderCompositor::BeginFrame, but WR doesn't call RenderCompositor::StartCompositor, then we'd clear but not draw any surfaces.

Flags: needinfo?(matt.woodrow)
Blocks: gfx-triage

Possibly related to this - Bug 1697310 - about:support fails to render properly with software fallback

(In reply to Matt Woodrow (:mattwoodrow) from comment #5)

If there's a frame where gecko calls RenderCompositor::BeginFrame, but WR doesn't call RenderCompositor::StartCompositor, then we'd clear but not draw any surfaces.

I confirmed that it happened.

Flags: needinfo?(sotaro.ikeda.g)
Assignee: nobody → sotaro.ikeda.g

This seems like maybe a similar problem to bug 1696025 where we realized wr_renderer_update can result in composite_native->start_compositing->StartCompositing being called when not inside the scope of BeginFrame/EndFrame. Not quite the same, but in the same family of bugs maybe.

No longer blocks: gfx-triage
Attachment #9207977 - Attachment description: Bug 1686800 - Call mCompositor->EndFrame() only when StartCompositing() was called → Bug 1686800 - Call mCompositor->EndFrame() only when StartCompositing() is called
Pushed by sikeda.birchill@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/200f23c57336 Call mCompositor->EndFrame() only when StartCompositing() is called r=lsalzman

https://hg.mozilla.org/mozilla-central/rev/200f23c57336

Status: NEW → RESOLVED
Closed: 4 years ago
status-firefox88: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: