846535 - Investigate triple buffering for content drawing (triple-buffered BasicShadowableThebesLayer)

Status: RESOLVED WONTFIX

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

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

When the gfx pipeline is working "correctly", buffer swaps are very quick and content spends very little time blocked on the compositor.  But when we have hiccoughs and start dropping frames, content can end up blocked on the compositor for longer periods due to bad timing.  The extra blockage can cause more frame skipping, etc.

One thing we can try relatively easily is triple-buffered content drawing.  This is a memory/speed tradeoff that's actually quite easy to make, since it's easy to measure.

Comment 1

[Jason Smith [:jsmith]]

Does this bug have any relationship to why we are seeing the BasicShadowableThesbesLayer crash in bug 834372?

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

And even when the pipeline is operating normally, triple buffering returns the few hundred us - 1ms taken by the synchronous IPC transaction to the content frame budget.

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Nope, not a thing.

Comment 4

[Jerry Shih[:jerry] (UTC+8) (inactive)]

We should check the profile result to see if we need triple-buffer or not for content.

Comment 5

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information