Two possible complications are when the gpu process crashes in the future when the display compositor moves there or when we evict frames.

What's the benefit of the proposal?

1. A possibly simplified API: Only need to submit a CompositorFrame without attaching a LocalSurfaceId.

2. Fewer bits to serialize / deserialize with simple CompositorFrames but this probably insignificant compared to the size of the CompositorFrame.

I see the main advantage being a simpler API, really. With the current API, a client could (ab)use SubmitCompositorFrame to ping-pong between two different LocalSurfaceIds, for example. An API that explicitly exposes LocalSurfaceId as a synchronization primitive would less likely be misused. This is by no means a priority, but just an observation.

This sounds like a subidea of the general idea of CompositorFrame deltas instead of sending the full state every frame.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Fady to triage please.

I think this is still a nice to have. Assigning to mohsen@ if he wishes to pick it up at some point.