Re: mir's internal renderer + other shells

2014-04-28 Thread Kevin DuBois
I appreciate that its difficult to see the end-goal of my plan here when I try to propose things in digestible/reviewable chunks of a thousand or so lines at a time. If you're interested (or concerned) about where this is all going, check out: http://bazaar.launchpad.net/~kdub/mir/future-default-d

Re: mir's internal renderer + other shells

2014-04-02 Thread Kevin DuBois
Yeah, I hope it can be tied into multithreaded compositor, although I don't know how tough this is. We've been on the same page from a high level for quite some time, I guess it just comes down to planning the low level details on how the code sholud shape up. I've been pouring over this a bit, a

Re: mir's internal renderer + other shells

2014-04-01 Thread Alexandros Frantzis
On Mon, Mar 31, 2014 at 03:04:29PM -0700, Kevin DuBois wrote: > [1] Last I've heard about QtSG, DefaultDisplayBufferCompositor is the place > that needs replacement). Correct me if things have changed :) QtSG provides its own rendering threads, which are difficult to manage externally and to dise

Re: mir's internal renderer + other shells

2014-03-31 Thread Daniel van Vugt
I think this is essentially what I was trying to get at in the "Compositor / Renderer" thread on 21 March. So we're on the same page. It's worth noting that the concepts: DisplayBufferCompositor DefaultDisplayBufferCompositor Renderer GLRenderer are all specific to MultithreadedComposito

Re: mir's internal renderer + other shells

2014-03-31 Thread Christopher James Halse Rogers
On Tue, Apr 1, 2014 at 12:38 AM, Kevin Gunn wrote: On Sun, Mar 30, 2014 at 9:06 PM, Daniel van Vugt 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 c

Re: mir's internal renderer + other shells

2014-03-31 Thread Kevin DuBois
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 sa

Re: mir's internal renderer + other shells

2014-03-31 Thread Kevin Gunn
On Sun, Mar 30, 2014 at 9:06 PM, Daniel van Vugt < 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 Uni

Re: mir's internal renderer + other shells

2014-03-30 Thread Daniel van Vugt
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

Re: mir's internal renderer + other shells

2014-03-28 Thread Daniel d'Andrada
On 28/03/14 17:47, Mirco Müller wrote: Am 28.03.2014 20:48, schrieb Kevin DuBois: ... 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 inte

Re: mir's internal renderer + other shells

2014-03-28 Thread Mirco Müller
Am 28.03.2014 20:48, schrieb Kevin DuBois: > ... > 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 (