The case for a "SceneGraph"

Daniel van Vugt daniel.van.vugt at canonical.com
Fri Jul 19 10:02:01 UTC 2013


Yes indeed the shell is meant to implement the scene graph. But that 
implementation is still inside libmirserver. It needs to be pulled out 
of the server library.

Interface:       mir::compositor::Scene
Implementation:  mir::surfaces::SurfaceStack

That implementation should go in the shell, whenever feasible. Though 
there is a reasonable argument for keeping a nice fallback SurfaceStack 
implementation in libmirserver for simple shells.


On 19/07/13 17:55, Michał Sawicz wrote:
> W dniu 19.07.2013 01:58, Gerry Boland pisze:
>> What shell will need is, for every surface, the following properties:
>> - x, y, z, width, height
>> - opacity, visible
>> - scale
>> - ability to set more complex transformations/shaders, so can desaturate
>> surface colours, do more advanced animations, blurs etc.
>>
>> Shell will implement window management through QML. I would like to have
>> as much flexibility with surfaces as the Qt Scenegraph gives me with
>> Items [1] [2].
>
> FWIW every time I think of a list of things we'll need to communicate to
> the compositor, it feels like we're doing something wrong. We'll
> basically have two SceneGraphs (one of the shell, one Mir-internal) and
> will have to keep them in sync.
>
> This, I feel, might make it really difficult to achieve some UX that
> we're wanting for. It also makes it difficult to think security when
> letting others render to the shell (think video/map in dash, custom
> infographics, even OSK).
>
> I'm sure it was discussed before, but can you guys please give me a
> summary why it's not possible to just keep the shell's scenegraph (in
> our case the Qt/QML one) in play? Or if there maybe is another way for
> shell's scenegraph to another process's surface for "internal" composition?
>
> Cheers,
>
>
>



More information about the Mir-devel mailing list