A lot of parts of the system expect draw and swap acks when submitting frames or making redraw requests to the compositor. With Blimp its hard to define what the correct behaviour should be, the draws are actually happening on the client. Faithfully sending draw/swap acks from the client back to the engine doesn't make sense when dealing with a high network delay or partition.
At the same time, most use cases for these acks revolve around frame throttling (for instance resize is a lock step, we stall events in the browser till a frame is sent back to the renderer), and waiting for CompositorFrames here does't make sense.
Comment 1 by khushals...@chromium.org
, Dec 8 2016