The case for a "SceneGraph"

[Gerry Boland]

On 23/07/13 19:45, Thomas Voß wrote:
> On Tue, Jul 23, 2013 at 6:01 PM, Gerry Boland
> <gerry.boland at canonical.com> wrote:
>> On 19/07/13 13:34, Alan Griffiths wrote:
>>> On 19/07/13 10:55, Michał Sawicz wrote:
>>>> 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?
>>>
>>> Mir components have a dependency on the scenegraph to provide them with
>>> information. This dependency exists in several contexts - e.g. system
>>> compositing and session compositing. There needs to be a better
>>> abstraction of these needs within Mir than exists at present because we
>>> are beginning to encounter issues like
>>> https://code.launchpad.net/~robertcarr/mir/session-transactions/+merge/175669.
>>>
>>> As to the suitability of the Qt scenegraph: the compositor, in
>>> particular, needs fast response to its queries - so I'm doubtful about
>>> implementing them across language boundaries. (I also suspect that it
>>> would be hard to satisfy all the functional requirements in Mir this way.)
>>>
>>
> 
> Not entirely sure where the notion of a language boundary comes from tbh.
> 
> The idea is simple: We collect all of Mir's internal requirements
> towards the scenegraph into interfaces. All internal logic works in
> terms of these interfaces and the implementation is injected from the
> outside. This could be a default implementation for simple shells
> (i.e., not Unity), e.g., the system compositor. Unity then is free to
> come up with a simple glue layer that implements Mir's interfaces for
> the scenegraph leveraging the existing Qt scenegraph. With that,
> surfaces would be available as first class citizens to Unity, and Mir
> is happy.

I'm  glad to have this confirmed, as I had suspected this was possible,
but I wasn't clear if it was considered the correct "thing to do".

What cast doubt for me is that in Mir, the interfaces and the default
implementation are freely mixed, and so me writing my own replacement
implementation feels like I'm overriding a significant chunk of Mir -
and thus doing something wrong.

I would find a stronger divide between the interfaces and the default
implementation more reassuring - would moving the interfaces into a
separate directory from the implementation be an idea?

<snip>

>> One great advantage of QtWayland is that the surface's texture itself is
>> pulled into the Qt scenegraph, and wrapped in a QQuickItem, so all
>> graphical effects available to QML can be applied to the surface.
>>
> 
> +1, it will help us to accelerate shell development significantly.
> 
> Agreed, I really like this
>> So that's my question: why not emulate QtWayland's approach and use Qt's
>> scenegraph and renderer?
>>
> 
> +1.

Ok, I'm delighted you approve. I think this is a task to pursue.
Thanks!
-Gerry