mir's internal renderer + other shells

[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, and here's my make-things-nice plan as
far as the demoshell/usc/android overlay work is concerned

1) DefaultDisplayBufferCompositor is becoming less complex. Step one (in
progress) is to make this work on the list instead of operators/filters on
the scene. This also involves fixing the locking scheme we have around the
Scene/Compositor interactions.

2) once we've transitioned to working solely on the Renderablelist, we
should transition Mesa to doing its hardware optimizations (bypass) from
within the DisplayBuffer. [1]

3) at this point, DefaultDisplayBufferCompositor is pretty simple. We can
write an alternative implementation for the demo shell that adds the drop
shadows by simply adding Renderables to the list that the scene is
producing.

4) simplify GLRenderer so it will just draw the renderables given to it
(and not allow for injecting different primitives via the tessellate
override). Android can then use it to draw the Renderables to the screen
when the Android drivers reject the surface as an overlay


Cheers,
Kevin


On Tue, Apr 1, 2014 at 4:49 AM, Alexandros Frantzis <
alexandros.frantzis at canonical.com> wrote:

> On Mon, Mar 31, 2014 at 03:04:29PM -0700, Kevin DuBois wrote:
> <snip>
> > [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 disentangle from the actual rendering operation. So,
> as a first step at least, the plan is to override the mc::Compositor
> completely.
>
> We will evaluate how well this works, and whether it's worth
> trying to make QtSG cooperate with the existing MultithreadCompositor
> and DisplayBufferCompositor infrastructure (which I would prefer).
>
> Thanks,
> Alexandros
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20140402/e2623496/attachment.html>