Code review comment for lp:~mir-team/mir/chain-simplification

Weak disapprove.

So, I think this is less typing in the uncommon case in return for higher complexity everywhere.

I don't think having more types makes the code more complex. I think having more types, each of which is conceptually atomic, makes the code *less* complex because the type gives you more information.

This makes the MirRenderSurface type more complex - it's no longer a generic handle to some sort of rendered content, it's now *sometimes* a generic handle to some sort of rendered content and *sometimes* a specific thing you can submit buffers to. You can't tell how it's being used without reading the code.

If we really want to rearrange how MirRenderSurface works we could call it MirContentSinkId or something, re-introduce the mir_connection_create_{buffer_stream,presentation_chain,eglstream}, and add mir_{buffer_stream,presentation_chain,eglstream}_bind_id($OBJECT, MirContentSinkId id).

Finally, this is optimising for the uncommon case. The majority of code that interacts with MirRenderSurface will just pass it to an EGL implementation¹ and go to town. The code that *doesn't* just pass it to an EGL implementation is going to associate it with a software-backed MirBufferStream and render to that.

This reduces the length of (unrepresentative) example code and driver code, but does not change expected real-world code.

¹: Or other hardware abstraction layer, like GStreamer.