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.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
