What is a MirRenderSurface?

[Kevin DuBois]

Hmm, let me try to rephrase my point, I've lost track of what is in
disagreement. We have a new thread "Does Mir have to pretend to be
SurfaceFlinger" that we can talk about our relationship to drivers. So for
further discussion, let's just assume we only have the Mesa platform.

We have a few different technologies that we're supporting, or aim to
support:
EGL, Vulkan, software-rendering, multimedia decoders, multimedia encoders,
nested-passthrough [1]

The problem that I see with the current WIP header is that we assume for
the user that they want to use EGL. When they get a MirRenderSurface, they
can immediately plug that resource into the EGL driver. We then try to
support the other technologies by transmuting transmute to other
technologies from there. [2]

If the answer to "What is a MirRenderSurface" is "A MirRenderSurface is the
common interface that all technologies can use to upload pixel content to
the mirserver" (and stop me here if this is not the right answer)

Then I think that we've already built this in MirPresentationChain.

[1] nested-passthrough is really support for building a generic display
server on top of the mirclient api.
[2] We build MirBufferStream from MirRenderSurface here:
http://bazaar.launchpad.net/~cemil-azizoglu/mir/mir-render-surface-v3/view/head:/src/include/client/mir_toolkit/mir_render_surface.h#L60
and I'm going out on a limb to assume that there's a similar function for
MirPresentationChain in the works.

On Thu, Sep 8, 2016 at 2:18 PM, Cemil Azizoglu <cemil.azizoglu at canonical.com
> wrote:

>
>> We quite literally cast MirRenderSurface* to EGLNativeWindowSurface in
>> the current WIP:
>> http://bazaar.launchpad.net/%7Ecemil-azizoglu/mir/mir-render
>> -surface-v3/view/head:/playground/eglflash_render_surface.c#L112
>>
>
> ​Perhaps, I should point out that our EGLNativeWindowType is not (and
> cannot be) 'MirRenderSurface'. It's void*.​ This is because we (have to)
> pretend to be other platforms (Android). That's what the cast is for. So if
> we get technical, our EGLNativeWindowType is 'void*'. We are not painting
> ourselves in a corner with a type that is not universal enough. So if Mir
> appeared in an EGL header, it would have 'void*' not 'MirRenderSurface*' as
> its native window type.
>
>
>>
>> This is why I'd much rather create an EGLNativeWindowType for the user
>> than try to tell all the drivers out there that they have to adopt
>> MirRenderSurface as their windowing type.
>>
>
> I disagree. ​A platform absolutely has to define its own type, and the
> drivers must adopt it. (Modulo the fact that we don't impose the
> MirRenderSurface type as that because of the need to support Android.)
>
>
>> Its mesa-specific thinking to think that we can define the window
>> interface for every
>>
>
> ​There is nothing Mesa-specific here. A platform defines the type and the
> driver implementer adds support for it around that type. This is what every
> platform has to do. (Except, for platforms that we pretend to be...like
> Android).
>
> As you see I'm having to add 'except' to the statements above, because
> Android is the exception, not Mesa.
>
> If we want to redefine our mesa interface, that's alright by me, and its
>> even fine to define our mesa interface to /be/ the mir client interface.
>> The problem is that we're trying to define our windowing type for platforms
>> where we cannot define the windowing type.
>>
>
> ​We absolutely can and should....except again for Android.​
>
>
>
>> It *does* have implications for how we implement MirRenderSurface on
>>> Android; specifically, it means that MirRenderSurface needs to be a
>>> SurfaceFlinger window. But even this doesn't tie Mir to EGL here - if
>>> MirRenderSurface can masquerade as a SurfaceFlinger window it should also
>>> work for Android Vulcan, which expects a SurfaceFlinger window, and *does*
>>> also work for the HW video encoding, which expects a SurfaceFlinger window.
>>>
>>> 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.
>>>>
>>>
> Mir native window type is not in EGL headers yet. This "non-obvious-ness"
> can easily be fixed when we add it in https://www.khronos.org/
> registry/egl/api/EGL/eglplatform.h
>  as a platform.​
>
>
>
>> 3) It puts MirPresentationChain and MirBufferStream as second-class
>>>> citizens. Having to
>>>>
>>>
> ​Who says that they should be first-class citizens? They are specific
> implementations that are prone to change and deprecation. That said, the
> fact that you can't use a MirRenderSurface without a backing of BS or PC
> would still make them a "first class citizen" anyways.
>
> ​Regards,​
>
> ​Cemil​
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20160909/73607d5e/attachment-0001.html>