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.
Bug 1946049 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
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.