mir's internal renderer + other shells

[Christopher James Halse Rogers]

On Tue, Apr 1, 2014 at 12: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.

We assume *something* as a fallback. In the medium term we're going to 
want to have a pure-software, super cut-down unity-system-compositor we 
can shove in an initramfs to provide a full kernel-init-to-shutdown 
system compositor. That's going to want to be GL-less.


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

I think it's a reasonable expectation that people will use an existing 
toolkit (or write a new one) for any non-trivial shell - all the 
existing shells have done so (Nux for Unity, St for GNOME Shell, Qt for 
KDE). We should make this expectation explicit.

Hm. Additionally, how does this affect how our shell interfaces should 
look?