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.v...@canonical.com>wrote: > >> On Tue, Jul 23, 2013 at 6:01 PM, Gerry Boland >> <gerry.bol...@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@lists.ubuntu.com >>> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/mir-devel >> >> -- >> Mir-devel mailing list >> Mir-devel@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/mir-devel >> > -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
