Code review comment for lp:~andreas-pokorny/mir/nbs-resize-first-stream-of-surface

> *Needs Discussion*
>
> It seems that the client API lacks a mir_buffer_stream_set_size() and adding
> that would be a better fix than this proposal.
>
> But I'm concerned that clients might want to make an atomic update of size and
> scale. Is the "correct" approach to create a new buffer stream?

Existing behavior with and without mir_surface_spec_set_streams was that the server controls the size of the first buffer stream and does not care about the other. At the moment the server decides based on the --nbuffers=3 vs --nbuffers=0 whether the first buffer stream is resized or not.

The release-create-with-new-size approach led to hang ups and allocation failures - and those are fixed here:
lp:~andreas-pokorny/mir/fix-buffer-release-requests-after-buffer-stream-destruction

The recreate approach has the advantage that it is immediately clear that the first buffer you get from the buffer stream will have the right size. Additionally the screen update would be tied to the necessary mir_surface_apply_spec call. While with the _set_size approach there are arguments to have it happen instantly or only after the next buffer swap..

But a current implementation detail makes the recreate approach a bit more resource intense since on creation three buffers are allocated. With a sequence of resize events two thirds of all created buffers are just allocated and freed without use. I assume that problem can be solved through an implementation change in mirclient.