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.g...@canonical.com
<mailto:kevin.g...@canonical.com>> wrote:
On Sun, Mar 30, 2014 at 9:06 PM, Daniel van Vugt
<daniel.van.v...@canonical.com
<mailto:daniel.van.v...@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
<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 <mailto:Mir-devel@lists.ubuntu.com>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/__mailman/listinfo/mir-devel
<https://lists.ubuntu.com/mailman/listinfo/mir-devel>
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com <mailto:Mir-devel@lists.ubuntu.com>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
