The case for a "SceneGraph"

[Gerry Boland]

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

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.

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.

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.

So that's my question: why not emulate QtWayland's approach and use Qt's
scenegraph and renderer?

Thanks
-Gerry