mir's internal renderer + other shells

[Daniel van Vugt]

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.

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

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

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