Code review comment for lp:~cemil-azizoglu/mir/mir-render-surface-v3

<RFC-response to the header>

I think that seeing exactly what type of object MirRenderSurface is in relation to MirBufferStream and MirPresentationChain would be helpful, and how each all of the technologies (EGLStreams, EGLNativeWindow, Vulkan, sofware rendering, and fine-grained multimedia/nested server) and backends (mesa, android, various driver vendors) tie into this with examples.

What levels of abstraction we're providing to the users seems to be in flux, so not quite sure what the goals are, even after scanning over the doc from the last sprint. It seems like the goal of the "MirRenderSurface" line of work is to give more flexibility to mesa, and only jump API once there.

We really work around multiple interfaces with mirclient, and I don't think its best to try to come up with a 'mirclient' interface that services mesa and our users, and treats blobs like android or nvidia as special cases. We have a few different interfaces to support, depending on the technology, and usage pattern.

user/mirclient --> mirclient API
mirclient/mesa --> src/platforms/mesa/client/native_surface.h API
mirclient/vulkan --> ?? (guessing that we can probably work with improvements to mesa's existing native_surface.h)
mirclient/android --> ANativeWindowBuffer
mirclient/nvidia --> ?? (guessing some nvidia headers)

The whole point here is that we should assume that we don't have control over the mirclient/{driver} interface (because we usually don't, esp if we get fixed blobs), and mesa is the happy exception where we can contribute.