[enhancement] Mir protocol design prevents clients from ever being more than double-buffered
The Mir protocol design prevents clients from ever being able to gain a performance advantage beyond double-buffering. This means clients which do a lot of rendering need to keep up with double-buffering deadlines to meet the compositor's frame rate. And they can never take advantage of the catch-up that triple (or more) buffers should provide to eliminate missed frames.
The problem is:
When a client tells the server that SurfaceId is ready for rendering, it must then wait synchronously for a single Buffer in return. Thus even if the surface has more than two buffers, the protocol design forces clients to only be able to handle two at once.
This causes a performance bottleneck where even though the server might have free buffers ready to send to the client, it can't do so until the client calls next_buffer a sufficient number of times.
The solution would be to not make next_buffer return a Buffer. Instead have buffers arrive from the server asynchronously, as soon as they can. Much like the way we deliver MirEvent's.
- Mir protocol design prevents clients from ever being more than double-
+ [enhancement] Mir protocol design prevents clients from ever being more
+ than double-buffered