Regardless of what EGL (or any other API) needs, there needs to be a way for Mir platform to generically represent a unit of renderable (hw or sw) with a distinct type. That's what MirRenderSurface provides. "Generically" in the sense that it doesn't matter what it's backed by (BS or PC or whatever), and it can be passed around (to other APIs, not just EGL) freely. Whereas, if we pass around, say, a BS handle then we become dependent on a backend that we may want to change or even deprecate in the future.
Also, EGL doesn't impose platforms to have an EGL specific type. A platform has its own type, and EGL is *made* to work with it. Here's a comment from the EGL header : /* The types NativeDisplayType, NativeWindowType, and NativePixmapType * are aliases of window-system-dependent types, such as X Display * or * Windows Device Context. They must be defined in platform-specific * code below. The EGL-prefixed versions of Native*Type are the same * types, renamed in EGL 1.3 so all types in the API start with "EGL". That means we should have one consistent type that may take different forms depending on the backend. So saying "A MirRenderSurface is an EGLNativeWindowType" is not the right way to look at it. Because there is nothing EGL-specific about a MirRenderSurface. As you know, ANativeWindow in Android, for instance, is not specific to EGL. It just represents a native window for Android for s/w and h/w. MirRenderSurface should be considered the same. You have a point in saying that we already expose clients with too much info on BS & PC. Perhaps we shouldn't, but that's a separate discussion. Regards, -Cemil Cemil Azizoglu Mir Display Server - Team Lead Canonical USA On Wed, Sep 7, 2016 at 12:34 PM, Kevin DuBois <kevin.dub...@canonical.com> wrote: > Two ways to answer this question make sense to me: > > 1) A MirRenderSurface is an EGLNativeWindowType > 2) A MirRenderSurface is a mf::BufferStreamId (ie, it is the token > representing server-side) > > We currently seem to be saying that MirRenderSurface are both. [1] > > (crux of my point) > Given that there exists software, vulkan, multimedia, and > nested-passthrough, it doesn't make sense to me to answer that "A > MirRenderSurface is 1) AND 2)", because all of those technologies don't > care about EGL. > We shouldn't make an assumption that the user will be using EGL, because > we have clients who specifically want a place to draw without having > anything to do with EGL. > > So, given that, I wrote up how the headers would look if we decide > MirRenderSurface is an EGLNativeWindowType or if we decide MirRenderSurface > is a mf::BufferStreamId. I attached a sketch of the headers to this mail, > and also catted the contents to pastebin > <http://pastebin.ubuntu.com/23146845/>. [2] > > I think first we have to agree that the answer is "1) OR 2)" instead of > "1) AND 2)". > Both versions of the headers make sense from the client's perspective, > although we should go back-and-forth on the merits of both approaches of > course, once we've figured out what MirRenderSurface is. > > Thanks, > Kevin > > [1] > In the last version of the headers that I've seen, we have a conversion to > a MirBufferStream (ie, MirRenderSurface is a mf::BufferStreamId) here > <http://bazaar.launchpad.net/%7Ecemil-azizoglu/mir/mir-render-surface-v3/view/head:/src/include/client/mir_toolkit/mir_render_surface.h#L55>, > and we have an implicit conversion here > <http://bazaar.launchpad.net/%7Ecemil-azizoglu/mir/mir-render-surface-v3/view/head:/playground/eglflash_render_surface.c#L112> > (ie, MirRenderSurface is also a EGLNativeWindowType) > > P.S. > Topic has come up in discussions here: > https://code.launchpad.net/~cemil-azizoglu/mir/use_egl_ > native_window/+merge/304726 > and the WIP branch here: > https://code.launchpad.net/~cemil-azizoglu/mir/mir-render- > surface-v3/+merge/304536 > > P.P.S > We also discussed a bit about client vs driver interfaces. I think > answering this mail is the primary topic, and will send a follow up mail to > make sure we're on the same page about the different technologies/semantics > going on. > > -- > Mir-devel mailing list > Mir-devel@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/mir-devel > >
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
