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

> > 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).

I think I was thinking that the buffer allocator will create a Shm/GL/Vulkan buffer and *return* it as a Shm/GL/Vulkan buffer to the renderer.

Code that only cares about generic “bufferness” can still use mg::Buffer, but the renderer is intimately tied up with its buffer type.