On Wed, Sep 7, 2016 at 8:01 PM, Christopher James Halse Rogers < ch...@cooperteam.net> wrote:
> > > On Thu, Sep 8, 2016 at 5:09 AM, Cemil Azizoglu < > cemil.azizo...@canonical.com> wrote: > >> 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. >> > > Right. There was a point (long ago) at which MirSurface was sort-of this > atomic-unit-of-renderable, but with cursor-renderables and > multiple-renderables-per-surface this went away. > > It is useful to have an absolutely minimal ‘this is a thing that can have > image content posted to it’ concept; MirRenderSurface should be that. > (Indeed, I'm not sure that that MirRenderSurface should even have a *size*, > and it definitely shouldn't have a pixel format; I've remarked as such on > the prototype branches). > > I'm on board here, right up until we try to cast MirRenderSurface to EGLNativeWindowType. (This is what I called "Option 2 in the OP). The 'absolutely minimal' concept is a mf::BufferStreamId, and then the user has to tell us what semantics they want to use to upload their content. Being able to cast MirRenderSurface to differing native rendering technologies: 1) Is not scalable. In the current spike we're really only casting to EGLNativeWindowType, but will we cast to gstreamer handles? Can I just make all the mir_presentation_chain() functions just take a MirRenderSurface instead of a MirPresentationChain? (same with the mir_buffer_stream() functions). Its really handy for EGL, but unnecessarily ties all other ways of using Mir to EGL. 2) Its not obvious how to use this. The casting to an EGLNativeWindowType has to be pointed out in comment-headers, or gleaned from reading example code. 3) It puts MirPresentationChain and MirBufferStream as second-class citizens. Having to create an EGLNativeWindowType first, and then create a MirPresentationChain doesn't make sense (unless from the vantage of favoring EGL to the detriment of the other technologies). It is more work for us to create an EGLNativeWindowSurface up-front (or via an even more complicated system of deferred type realization) regardless of whether the user wants to use EGL or not. So, by tweaking the header like this: (repost: http://pastebin.ubuntu.com/23149827/) These problems are resolved, and internally and externally, it becomes clearer what's going on. > 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. >> > > Right. EGLNativeWindowType is defined by the platform as “a handle to the > thing you can render to”. > > This is why Mir's Android support is misleading. On the Android platform > Mir pretends to be SurfaceFlinger, and this is obviously awkward, even > though Google has deliberately made it possible. > > But this really is going to be a special case. We're not going to pretend > to be Wayland to get closed-source Mali support; we're not going to pretend > to be X11 to get closed-source NVIDIA support, although we could (at the > cost of significant madness) in both cases. > > This is a second topic from the one I originally brought up (having to do with that we can cast MirRenderSurface to different rendering technologies types). This topic is more what do we provide to drivers and how we define our responsibilities to the different platform. It needs to be addressed, but I think clearing up the MirRenderSurface wip header is step one. Maybe I'll diverge the email chain to talk about Mir's relationship to EGL/drivers.
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
