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.

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

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.

Nope, not a thing.

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

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

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