mir's internal renderer + other shells

[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-display-buffer-compositor/view/head:/src/server/compositor/default_display_buffer_compositor.cpp#L49

This branch still has some kinks to work out (mostly lower level hwc stuff
at this point), but hopefully you get a good idea of how the abstraction
for mesa and android makes writing a DisplayBufferCompositor
straightforward.

We still have that nice 'if/else block' around hardware optimizations, it
just now works for android as well as mesa in this branch.

Cheers,
Kevin


On Wed, Apr 2, 2014 at 2:28 PM, Kevin DuBois <kevin.dubois at canonical.com>wrote:

> 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/20140428/5a52aecf/attachment.html>