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
