Code review comment for lp://qastaging/~afrantzis/mir/buffer-bind-to-render-image

> AFAIK, the verb "bind" is very much a GL specific concept. So the "gl_" prefix
> made sense in communicating that it must be called in a GL context. Not yet sure
> how much it's been generalized now and if this yet warrants removal of the "gl_" prefix.

The main difference is that this method can return information that the renderer can use. For example for software rendering it could return a struct describing a memory area. At the same time, however, the API needs to support the GL way of doing things (implicit context).

> Thinking about it, I kinda wonder to what extent Buffer is a sensible abstraction,
> or whether we'd be better off with three different ShmBuffer, GLBuffer, VulkanBuffer
> interfaces on top of a smaller Buffer that contains the common elements - id, size,
> stride, buffer format. We already don't support read/write on GL buffers, and
> NativeHandle is purely an IPC thing which would probably be better if implemented
> in the platform? Maybe?

So, if I understand correctly, the buffer allocator will create a Shm/GL/Vulkan buffer (an interface specified by the corresponding renderer) which will be returned as an mg::Buffer and then each renderer can dynamically cast it back to its original type (since it knows what type to expect). This could work, as long as all the operations that extract rendering-specific information happen in code that is specific for each renderer type.

The intention is to offer something similar for the DisplayBuffer interface (since renderers need a render target). There are some complications in this case, since some renderer-related operations, e.g. make_current(), are currently called in rendering-agnostic code due to the nature of per-thread GL contexts, but perhaps we can make this work.