1946049 - The refresh driver's backpressure fires even though the compositor process idles a lot

Status: NEW

(Core :: Graphics, defect)

Description

[Nicolas Silva [:nical]]

Edit: This bug is in fact about the compositor poorly scheduling frames when a scene is built right after vsync. See comment 2.

--

See for example this profile: https://share.firefox.dev/3WPd26F

There are a bunch of RefreshDriver is waiting for paint markers but the compositor and and WebRender are able to process and render all incoming display lists fairly quickly (within 7ms of the content process sending the transactions) before going to sleep. We can clearly see that the compositor is able to keep up with the content process and the backpressure mechanism should not trigger, but it does.

It could be that DidComposite messages get enqueued in the main thread's event loop behind a lot of stuff and only get processed much later after they have been received, or we somehow lose track of some transactions and incorrectly consider than we are more than two transactions ahead of the compositor.

This results in reduced/inconsistent refresh pacing on the content process.

Comment 1

[Markus Stange [:mstange]]

If you capture a profile with IPC markers, it should tell you whether they're getting queued up the way you hypothesize.

Comment 2

[Nicolas Silva [:nical]]

Thanks Markus. A profile with IPC markers shows that the queuing hypothesis is incorrect. I did another profile with more instrumentation showing for RefreshDriver related events the corresponding transaction ids and the list of pending ones.

What gave me the impression that the refresh driver was throttling incorrectly, was that the compositor process was idling a lot. What is happening is that the throttling logic is operating as intended (no ticks while two transactions are already in flight in the compositor process), but on the compositor side, unfortunate alignment with vsyncs cause transactions to arrive and the scene is built just a tad too late and we end up waiting an almost full vsync before rendering the frame, but the previous frame (which also waited an almost full vsync cycle) starts right then, looking like it belongs to this transaction instead of the previous one.

I still think that we should be able to not throttle when the compositor is idling a lot. The initial assumption that something wrong is happening on the content side is incorrect so I'll re-title the bug to preserve the context and profiles.

Comment 3

[Nicolas Silva [:nical]]

Attachment: Illustration of the throttling kicking in when scene building narrowly misses vsync

Here is an illustration of the problem with two (color coded) transactions overlapping (and causing throttling) with a lot of latency and idle time caused by narrowly missing the vsync after scene building.

Comment 4

[Markus Stange [:mstange]]

the throttling logic is operating as intended (no ticks while two transactions are already in flight in the compositor process)

This is not the intended behavior - the intended behavior is to allow one transaction to be in flight but not two.

Your illustration shows what would happen if we allowed no transaction to be in flight. That's what we don't want to happen and it's why TooManyPendingTransactions() uses 2 and not 1.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:bhood, could you have a look please?

For more information, please visit BugBot documentation.

Comment 6

[Nicolas Silva [:nical]]

Your illustration shows what would happen if we allowed no transaction to be in flight.

In the illustration, the green transaction is still in flight when the blue one starts so they do overlap. But no new transaction starts while both of them are ongoing.

the intended behavior is to allow one transaction to be in flight but not two.

You are right, I've been a bit loose with the terminology. If I understand correctly, the intended behavior is to allow ticks only if zero or one transactions are already in flight. Due to the nature of pipelining, this means that it allows up to two transactions to be in flight at any given time.

One thing that the illustration doesn't show is that we do have code to kick frame building up to 4ms after vsync in some cases. So in the simple illustrated situation, the green transaction should have started frame building earlier instead of waiting until the next vsync.
Yet, I do see in profiles that look like the illustration, with large gaps between the end of scene building and the start of frame building while WR is idle, so this logic does not trigger catch-up composites as much as I would expect it to, or it does not always get a chance to run for some reason.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:bhood, could you have a look please?

For more information, please visit BugBot documentation.