The case for a "SceneGraph"

[Gerry Boland]

On 23/07/13 23:03, Kevin Gunn wrote:
> hey all -
> Using Qt scenegraph sounds good to me....but one (or 2) question(s) though.
> In our long term plans of rootless X support, won't this mean the X apps
> have to be effectively be Qt windows to be treated as a node on the Qt
> scengraph ?
> e.g. legacy Xapp -> Xrender -> Qtwindow/node -> mir compositor (arbitrated
> by unity8/qt shell)

There is no need for X apps to have anything to do with Qt. Xrender will
supply Mir with a pixmap/texture, and that texture will be added as a
node to Qt's scenegraph.

So as far as Qt's scenegraph is concerned, an application is just
another texture to be rendered.


> In the case of unity8 does this preclude native mir clients ? (or at least
> will they have to "do something" special to be considered part of the
> scenegraph)

Mir does all the hard work for this, so shell just gets a texture per
client, and it does not matter to shell if that client is X-based or
native Mir.

> 
> maybe its not that big of a concern....from Qt scenegraph doc
> "Even though the node tree is mostly built internally by the existing Qt
> Quick QML types, it is possible for users to also add complete subtrees
> with their own content, including subtrees that represent 3D models."

Qt's scenegraph does give us a lot of flexibility. I believe with
QtWayland it merely adds a node with each application texture to the SG
tree. I think we can do the same. I do need to study QtWayland more closely.
-G


> br,kg
> 
> 
> On Tue, Jul 23, 2013 at 12:45 PM, Thomas Voß <thomas.voss at canonical.com>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.
>>
>>> 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
>>
>> --
>> Mir-devel mailing list
>> Mir-devel at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>>
>