When we enabled gfx.webrender.compositor on Windows we see a pretty noticeable COMPOSITE_TIME regression: https://colab.research.google.com/drive/15_-z-9cLox6GUm1Zs1DQK7TF2fdZ0Vb5?authuser=1#scrollTo=EgxKF-bvG-tu

COMPOSITE_TIME is the time from the beginning of WebRenderBridgeParent::MaybeGenerateFrame() to the end of RenderThread::HandleFrameOneDoc() this includes the 'SwapBuffers' which is likely where we're seeing this additional time come from. We should likely add some timing to measure this part specifically to see if that's where the extra time is coming from.

The priority flag is not set for this bug.
:jbonisteel, could you have a look please?

For more information, please visit auto_nag documentation.

We added a COMPOSITE_TIME_SWAP metric that measured the time spent in Commit() and Present() disabling the DirectComposition moves COMPOSITE_TIME_SWAP by approximately the same amount that COMPOSITE_TIME changes. We don't currently have any evidence that this extra time being spent in COMPOSITE_TIME actually makes Firefox slower. I believe we're just measuring more of the pipeline.