Closed Bug 1686800 Opened 3 years ago Closed 3 years ago

Black flash software webrender (d3d11 compositor) on Windows 10

Categories

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

defect

Tracking

()

RESOLVED FIXED
88 Branch
Tracking Status
firefox88 --- fixed

People

(Reporter: jrmuizel, Assigned: sotaro)

References

(Blocks 2 open bugs)

Details

Attachments

(2 files)

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
See Also: → 1687124

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)

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
See Also: → 1696025
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
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: