mir's internal renderer + other shells

[Kevin DuBois]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20140328/8d585557/attachment.html>