mir's internal renderer + other shells

Mon Mar 31 22:04:29 UTC 2014

I too think we should steer clear of a toolkit, and can assume people want
to write their own GL and GLSL. I'm concerned though that we don't have an
obvious location that we want people to plug in new rendering engines
though.

My big concern right now is that I don't see us rallying around the same
Renderer/Compositor interfaces in order to plug the QtSg and (USC/demo
shells). We're evolving, but divergently. It needs to be obvious what we
want the new-shell-writer to replace. Right now, its not obvious, and we
have the demo shell evolving along the lines of "expand mc::GLRenderer" and
the QtSG stuff evolving more along the lines of "replace the
DefaultDisplayBufferCompositor".

Our examples/ directory is where the new-shell-writer would probably look
first to learn how to do something cool, so we should point them in the
direction we want them to go. There's a split between what we recommend in
our examples, and what we're actually planning on using for the unity8
shell.

The best way I can see to rectify this is to allow for people to rewrite
the DefaultDisplayBufferCompositor, meaning we have a USC compositor
implementation, a fancy demo shell implementation, and a QtSG
implemenation. [1]
We are object-oriented after all :) This lets us arrange our interfaces
flexibly, we have a the different needs between the three.

The next step for driving at the triad of implementations would just be to
1) Continue making DefaultDisplayBufferCompositor smaller and smaller
(which I'm working on anyways to get overlays all hooked up)
2) split the GLRenderer somehow, instead of having one implementation with
different internal parts being overridden. We make it two implementations,
or we make it a cobbling together of different useful GL parts (I prefer
the two implementations, we are object oriented. The end result here would
be that mc::Renderer would get buried into the private headers, or be a
header private to examples/. [2] This also has the added benefit that we
don't have latent demo code in USC's call path.

Cheers
Kevin

[1] Last I've heard about QtSG, DefaultDisplayBufferCompositor is the place
that needs replacement). Correct me if things have changed :)
[2] IIRC, historically, mc::Renderer was originally just to test the
interactions between the compositor and the GL code. At some point it was
made public and overridable, and became a much bigger/more important
interface than we originally intended

On Mon, Mar 31, 2014 at 6:38 AM, Kevin Gunn <kevin.gunn at canonical.com>wrote:

>
>
>
> On Sun, Mar 30, 2014 at 9:06 PM, Daniel van Vugt <
> daniel.van.vugt at canonical.com> wrote:
>
>> This topic sounds like what I've been working on - moving the pieces
>> around so that anything and everyone can play nicely with Mir. It's really
>> an evolution toward reaching some common interface that Unity8/Qt and other
>> pure OpenGL shells could use simultaneously.
>>
>> On kdub's points:
>>
>>
>> > Does it mean that you don't have to write GL? [1]
>> At the moment, yes you have to use GL or a toolkit which uses GL (Qt).
>> However we are aiming to not even be dependent on GL if something else was
>> available.
>>
>>
> by this do you simply mean the interface between Compositor & Renderer
> will be devoid of GL ?
> and the "something else" could be HWC i suppose ?...but even then, we
> assume GL as a fallback.
>
>
>> > Does it mean that you don't have to write common GL algorithms? (eg,
>> > tesselation, drawing, texture stuff)
>> You can use the built-in drawing methods of GLRenderer (which themselves
>> are evolving and subject to change). In the purest sense I think all of
>> GLRenderer would become shell-specific. However that's not likely to happen
>> while it still contains important boiler-plate logic. I'm slowly working to
>> try and push boiler-plate into Mir and GL-bling into the shell.
>>
>>
> yeah, but +1 to what you describe. this actually allows gets that nice
> split of "convenience" for those that just need to use boiler-plate....and
> then "flexibility" for those that want to go all bling-y.
>
>
>>
>> > Does it mean that we give some pretty basic, simple interfaces that you
>> can plug your stuff in?
>> Yes, working on that re-"Compositor / Renderer". But I'm conscious that
>> we don't want to build a toolkit. We're not building a "toolkit" in the
>> normal sense but a set of interfaces for building shells.
>>
>>
> agreed, and i think its good to restate this. I think the creep of
> "toolkit into mir" is something we have to be on guard for.
>
>
>> > Does it mean that when mir's compositor is overridden libmirserver.so
>> > does not touch GL state at all?
>> Ideally that should be possible. GL should just be an option anyway.
>> Although the GL context is tangled up in the DisplayBuffer design right now.
>>
>> - Daniel
>>
>>
>>
>> On 29/03/14 03:48, Kevin DuBois wrote:
>>
>>> Hello mir folks,
>>>
>>> We have 4 users of mir in-flight right now:
>>> 1) unity8 (driving at using QtSG)
>>> 2) USC (using the default mir implementation)
>>> 3) the demo shell (using the default mir implementation, and overriding
>>> its functionality in some areas)
>>> 4) the demo server (using the default mir animation)
>>>
>>> I mostly want to think about 2, 3 and 4 at this email discussion, that
>>> is, how do we arrange for sharing the default mir compositor
>>> implementation with USC and the demo shell. (unity8 has its own ball
>>> rolling already with an effective fork of the mir implementation)
>>>
>>> Now USC is obviously important because its in production, and the demo
>>> shell is important too, because its making sure its easy to write a
>>> sensible shell from scratch.
>>>
>>> Now, 'easy to write a sensible shell from scratch' is a bit vague, we
>>> should hash out what that means in this email chain.
>>>
>>> Does it mean that you don't have to write GL? [1]
>>> Does it mean that you don't have to write common GL algorithms? (eg,
>>> tesselation, drawing, texture stuff)
>>> Does it mean that we give some pretty basic, simple interfaces that you
>>> can plug your stuff in?
>>> Does it mean that when mir's compositor is overridden libmirserver.so
>>> does not touch GL state at all?
>>>
>>> kdub's opinion:
>>> //begin
>>> Its kinda tricky to think about; I like to approach it from the
>>> perspective of someone who doesn't know much about mir's internals, but
>>> has written a GL game/program before and wants to try their hand at
>>> writing a shell, or perhaps someone with toolkit/GL experience who wants
>>> to try a shell. [2]
>>>
>>> Given this, what I would want is mir to handle all the junk about
>>> clients, ipc, buffer swapping, etc. I'd just want to write GL; my own
>>> shaders, my own algorithms, my own GL state. [3] I wouldn't really be
>>> interested in using mir's GL stuff (triangle tesselation? bah! I want to
>>> write zany jigsaw tessellations and name the vertex attrib what I want
>>> to name it!)
>>>
>>> So given this, I'd like to see the demo shell forking the USC rendering
>>> functionality at some point, not sharing very much at all. QtSG/unity8
>>> is already forking the rendering functionality. This kinda drives
>>> against the 'never duplicate code' instinct, but the 3rd party shell
>>> writer is probably /only/ interested in duplicating code.
>>>
>>> It also makes the USC/production default renderer implementation the
>>> lightest possible implementation one can get away with, while having the
>>> demo shell's implementation showing a more high power implementation.
>>>
>>> So maybe, we have to have 2 vertex/fragment shaders in the mir code
>>> base, as opposed to one set like we have now, but in the end, our
>>> interfaces are better for it, and the 3rd party implementers have an
>>> easier time bootstrapping too.
>>> //end
>>>
>>> Interested to hear other people's thoughts, I'd guess there's a few
>>> different 'how easy is easy?" answers floating around. Striking the
>>> right balance will get other shell rolling easily, without us having to
>>> support the myriad things in the USC implementation.
>>>
>>> Cheers,
>>> Kevin
>>>
>>> [1] we already have an approach aimed at the minimal-GL with
>>> unity8/QtSG/qml effort
>>> [2] There are of course lots of advanced coders who might be interested
>>> (like a phone vendor), but I tend to hearken back to my compiz fusion
>>> days https://www.youtube.com/watch?v=9GtMu5afIKg
>>> [3] Obviously, this is idealistic, the serious shell coder will
>>> eventually wade into more detail about the internal interactions of mir
>>> and its scene. But what gets people started coding is seeing its simple
>>> to plug your own stuff in there and see it hit the screen.
>>>
>>>
>>>
>> --
>> Mir-devel mailing list
>> Mir-devel at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/mir-devel
>>
>
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20140331/4add929e/attachment-0001.html>