The case for a "SceneGraph"

[Thomas Voß]

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.

> Qt's Scenegraph is C++. It offers internal APIs to extend it. I have to
> ask was it ever actually seriously considered? Just claiming it will be
> slow and won't do everything we need isn't much of an argument.
>

I do agree. IIRC, Qt's scenegraph leverages OpenSceneGraph internally,
and that is one fast implementation :)

> It is a bit late in the day for this discussion, but unless I'm
> mistaken, we've never really had it. I'm aware that changing direction
> at this stage would be tough though.
>
> I am concerned about having 2 independent scenegraphs, one for Mir and
> one for shell (Qt). Here are my reasons:
>
> 1. Duplication of effort
> Why not use an existing, flexible, well tested and performant
> scenegraph, instead of writing our own from scratch?
>
> 2. Synchronicity of 2 scenegraphs
> Unity8 will be animation heavy. Switching windows will involve animating
> both shell elements and mir surfaces. QML will be controlling those
> animations. For each frame am I guaranteed that the Qt scenegraph and
> the Mir scenegraph will be in perfect sync?
>
> 3. Complex visual animations
> Right now I wrap Mir's Surface API with a QQuickItem so the surface can
> be animated with QML. The surface is rendered by Mir, but properties of
> that surface can be manipulated by QML, so it is easily animated. This
> works for simple properties like position, opacity... but defining more
> complex transformations (for example a shader effect) on surfaces will
> be very tough to integrate into QML's animation framework.
>

+2, I do share these concerns.

> 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.

Thanks,

  Thomas

> Thanks
> -Gerry
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel