A possible solution here is to look at the primary surface-info when creating the gutter layers when surface-sync is disabled. But I think we decided that turning on surface-sync is the better solution? Let me know if you would rather we have a fix for non-surface-sync too.

I'm hoping to turn on surface sync on Mus+Ash very soon. I'm not sure if it's worth addressing this right now. In the limit, we can probably eliminate overdraw entirely. I was chatting with piman@, and his suggestion was essentially to emit SolidColorDrawQuads along with the the fallback SurfaceDrawQuad that is only included in surface aggregation if the primary surface is not available.

Basically, if the primary surface is available during Surface aggregation, then that means there's no gutter. If it isn't then we don't just use the fallback surface, we also emit an embedder specified right and bottom gutter.

I feel like the most efficient way to implement this is to have an optional gutter_rect on SurfaceDrawQuads. The fallback SurfaceDrawQuad has a gutter rect either equal to the primary SurfaceDrawQuad's rect or smaller (in the case of Mus+ash where we don't want to occlude the window decorations).

The gutter_rect does not ever get used by primary surfaces, but it's used by fallback surfaces in surface aggregator to compute a right and bottom SolidColorDrawQuad.

We can use the background color of the fallback Surface's CompositorFrame.

In the case of a transparent background color, we use a white gutter or some "gutter_color" specified on a SurfaceDrawQuad perhaps.

I know we probably aren't yet in full agreement as to how gutter should work but I believe this mechanism will work and will eliminate overdraw in the case where we have an available primary surface BUT the primary surface's availability hasn't propagated to the parent to update its gutters yet. I will experiment (hopefully this week_ and report back here. 

In particular, currently SurfaceLayer::SetFallbackSurfaceInfo always triggers a SetNeedsCommit, meaning that updating the fallback causes the parent to needlessly generate a new CompositorFrame. This seems rather unfortunate when it's possible that nothing visual has actually changed. Certainly this means that a temporary reference becomes a permanent reference sooner, but it creates more work in the critical path during a resize, for example.

There's nothing wrong with a temporary reference lingering for a little longer in kylechar's system, I believe.

I think if we implement guttering correctly, we can possibly avoid this SetNeedsCommit and let a visual change trigger a commit instead of a mere bookkeeping change.

My original suggestion was actually, instead of supplying a fallback SurfaceDrawQuad (where we then need to specify how to adapt it to mismatched sizes and so on), to supply a fallback CompositorFrame, which would contain the SurfaceDrawQuad for the fallback surface, as well as the gutter quads (if guttering is what we want, but it could also be scaling for e.g. video).

The idea being that at aggregation time, we'd take the CompositorFrame submitted to the primary surface if that exists, otherwise we'd take the fallback CompositorFrame.

I'm not married to the concept, but I think it has some nice properties.

Since I proposed this, rjkroege@ and I had another idea that might also do:

1. Propagate background color to the parent along with the rest of SurfaceInfo (size + device scale factor). 

2. Update gutter in the parent along with the fallback using the fallback SurfaceInfo's background color.

3. Surface draw occlusion eliminates gutter if the primary surface is available.

re comment #5: does that allow doing something different, e.g. doing scaling for video content (as mentioned in comment #4)?

Note that this is likely going to affect some of the telemetry results. So bumping P.

Now that surface sync is turned on, I think this is a non-issue? Can I close?