The case for a "SceneGraph"
kevin.gunn at canonical.com
Tue Jul 23 21:03:35 UTC 2013
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
e.g. legacy Xapp -> Xrender -> Qtwindow/node -> mir compositor (arbitrated
by unity8/qt shell)
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
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."
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"
> >> 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
> >> 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
> 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?
> > Thanks
> > -Gerry
> > --
> > Mir-devel mailing list
> > Mir-devel at lists.ubuntu.com
> > Modify settings or unsubscribe at:
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mir-devel