Closed Bug 1575419 Opened 2 years ago Closed 2 years ago

Too many sync PCompositorBridge::Msg_FlushRendering during window opening with CoreAnimation turned on

Categories

(Core :: Widget: Cocoa, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox70 --- fixed

People

(Reporter: mstange, Assigned: mstange)

References

Details

Attachments

(1 file)

Turning on CoreAnimation causes browser_startup_syncIPC.js to fail, see this try push:

sync IPC PCompositorBridge::Msg_FlushRendering 1 more times than expected before handling user events

I can see two main thread paints when a window opens. The first one is expected, but the second one is not. The second one is triggered with a call to markLayerForDisplay because the vibrancy region has changed, which happens during the WillPaintWindow() call in nsChildView::HandleMainThreadCATransaction(). So we're triggering another layer display while we are inside a layer display handler. This is unnecessary and we can just add guards to avoid it.

A try push will confirm whether this change actually fixes the test.

This also moves the MaybeScheduleUnsuspendAsyncCATransactions() call to the end
of HandleMainThreadCATransaction() so that we can't get re-suspended from within
WillPaintWindow().

Pushed by mstange@themasta.com:
https://hg.mozilla.org/integration/autoland/rev/0aa0dd2f418b
Don't allow triggering another main thread paint from within a main thread paint. r=mattwoodrow
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
You need to log in before you can comment on or make changes to this bug.