1761744 - 60Hz compositing without render reason markers

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Florian Quèze [:florian]]

I don't have steps to reproduce, but I saw 2 similar profiles that have "Composite" markers at 60Hz, but no "Render reason" markers.

The first profile comes from my Mac: https://share.firefox.dev/37V1WGD

The second comes from Alexandre's Linux machine: https://share.firefox.dev/36UVqz2

Nical, any idea about how we could get in this situation and/or which profiler markers need to be added to make this easier to understand next time we encounter it?

Comment 1

[Nicolas Silva [:nical]]

I don't have a very complete mental model of the frame scheduling stuff. I know that when I added the markers I didn't necessarily cover all possible reasons for producing frames.

That said the absence of RenderReason::VSYNC is interesting. VSYNC isn't a reason for rendering in itself, but I think that the absence of the VSYNC marker indicates that we are not making the frame wait for the next vsync, which reduces the question to a smaller set of the possible code paths.

This one for instance is worth keeping an eye on: https://searchfox.org/mozilla-central/rev/b671b6390e88672543b9b7c82132be655bd98856/gfx/layers/wr/WebRenderBridgeParent.cpp#2300

There are also skipped composites (when we are producing frame requests faster than webrender can render them, we skip the frame request and do it later when webrender has caught up, and that frame isn't waithing for vsync). Although those should show up with their own profiler marker.

I have just cooked a few patches to improve the coverage of the render reasons althoug I don't know whether it will cover all cases.

Comment 2

[Nicolas Silva [:nical]]

Attachment: Bug 1761744 - Tag frames coming from skipped composites. r=#gfx-reviewers

Also differentiate between skipped composites (too many pending frames) and discarded composites (paused or no display list).

Comment 3

[Nicolas Silva [:nical]]

Attachment: Bug 1761744 - Tag frames caused by the start of observe vsync. r=#gfx-reviewers

Also tag frames from FlushGenerateFrames.

Depends on D142232

Comment 4

[Nicolas Silva [:nical]]

Attachment: Bug 1761744 - Better tag frames coming from the async image pipeline manager. r=#gfx-reviewers

We schedule additional composites as long as there is a CompositeUntil timestamp. These composites need a special tag and shouldn't carry the tags of whatever led us to check the timestamps. In addition, we should add the ASYNC_IMAGE tag when GetAndResetWillGenerateFrame returns true even if some other reason led us to check it.

Depends on D142233

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/78cf3f44e522
Tag frames coming from skipped composites. r=gfx-reviewers,aosmond
https://hg.mozilla.org/integration/autoland/rev/1473c177b3f8
Tag frames caused by the start of observe vsync. r=gfx-reviewers,aosmond
https://hg.mozilla.org/integration/autoland/rev/b52be864f414
Better tag frames coming from the async image pipeline manager. r=gfx-reviewers,aosmond

Comment 6

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/78cf3f44e522
https://hg.mozilla.org/mozilla-central/rev/1473c177b3f8
https://hg.mozilla.org/mozilla-central/rev/b52be864f414

Comment 7

[Nicolas Silva [:nical]]

No occurences for a while.