<div dir="ltr"><div><div><div>Yeah, I hope it can be tied into multithreaded compositor, although I don't know how tough this is.<br><br></div>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.<br>
<br></div>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<br><br></div><div>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.<br>
<br></div><div>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]<br><br></div><div>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.<br>
<br></div><div>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<br>
<br></div><div><br></div><div>Cheers,<br>Kevin<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 1, 2014 at 4:49 AM, Alexandros Frantzis <span dir="ltr"><<a href="mailto:alexandros.frantzis@canonical.com" target="_blank">alexandros.frantzis@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Mar 31, 2014 at 03:04:29PM -0700, Kevin DuBois wrote:<br>
<snip><br>
<div class="">> [1] Last I've heard about QtSG, DefaultDisplayBufferCompositor is the place<br>
> that needs replacement). Correct me if things have changed :)<br>
<br>
</div>QtSG provides its own rendering threads, which are difficult to manage<br>
externally and to disentangle from the actual rendering operation. So,<br>
as a first step at least, the plan is to override the mc::Compositor<br>
completely.<br>
<br>
We will evaluate how well this works, and whether it's worth<br>
trying to make QtSG cooperate with the existing MultithreadCompositor<br>
and DisplayBufferCompositor infrastructure (which I would prefer).<br>
<br>
Thanks,<br>
Alexandros<br>
</blockquote></div><br></div>