Code review comment for lp:~cemil-azizoglu/mir/use_egl_native_window

> The instinct to have one "MirRenderSurface thing is good. But I think that
> mf::BufferStreamId is really the concept that's being looked for. All 3
> client-facing concepts are represented by mf::BufferStreamId in the end.

And this fits in well, esp in light of how multiple surfaces are arranged in MirSurfaceSpec.

If you add
void mir_surface_spec_add_render_surface(MirSurfaceSpec*, MirRenderSurface*, int width, int height, int displacement_x, int displacement_y);

to the two functions for BS and PC:
http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/include/client/mir_toolkit/mir_presentation_chain.h#L122

then if a user wanted to make a multi-content MirSurface, this would be easy to do both from the client api perspective, and from Mir's perspective internally.

Client perspective:
EG, making a french/italian/mexican/etc 3-bar-style-flag from the 3 components:

int bar_height = 200, bar_width = 200;
int full_width = 3 * bar_width, full_height = bar_height;
MirSurfaceSpec* spec = mir_connection_create_spec_for_normal_surface(connection, full_width, full_height, format);
MirPresentationChain* chain = mir_connection_create_presentation_chain_sync(connection);
MirBufferStream* stream = mir_connection_create_buffer_stream(connection, bar_width, bar_height, format, usage);
MirRenderSurface* rs = mir_connection_create_render_surface_sync(connection);
mir_surface_spec_add_presentation_chain(spec, bar_width, bar_height, 0, 0, chain);
mir_surface_spec_add_buffer_stream(spec, bar_width, 0, stream)
mir_surface_spec_add_render_surface(spec, rs, bar_width, bar_height, 2*bar_width, 0);
MirSurface* surface = mir_surface_create_sync(spec);

Mir's internal perspective:
mir_surface_spec_add_* will just add mf::BufferStreamId to the request. The server doesn't have to know what sort of client construct is present, as its all boiled down to NBS rpc transactions.