<div dir="ltr">hey all -<div>Using Qt scenegraph sounds good to me....but one (or 2) question(s) though.</div><div>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 ?</div>
<div>e.g. legacy Xapp -> Xrender -> Qtwindow/node -> mir compositor (arbitrated by unity8/qt shell)</div><div><br></div><div>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)</div>
<div><br></div><div>maybe its not that big of a concern....from Qt scenegraph doc</div><div>"<span style="color:rgb(54,53,52);font-family:'Open Sans',sans-serif;font-size:13px;line-height:20px">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.</span>"</div>
<div>br,kg <br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 23, 2013 at 12:45 PM, Thomas Voß <span dir="ltr"><<a href="mailto:thomas.voss@canonical.com" target="_blank">thomas.voss@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Jul 23, 2013 at 6:01 PM, Gerry Boland<br>
<<a href="mailto:gerry.boland@canonical.com">gerry.boland@canonical.com</a>> wrote:<br>
> On 19/07/13 13:34, Alan Griffiths wrote:<br>
>> On 19/07/13 10:55, Michał Sawicz wrote:<br>
>>> I'm sure it was discussed before, but can you guys please give me a<br>
>>> summary why it's not possible to just keep the shell's scenegraph (in<br>
>>> our case the Qt/QML one) in play? Or if there maybe is another way for<br>
>>> shell's scenegraph to another process's surface for "internal" composition?<br>
>><br>
>> Mir components have a dependency on the scenegraph to provide them with<br>
>> information. This dependency exists in several contexts - e.g. system<br>
>> compositing and session compositing. There needs to be a better<br>
>> abstraction of these needs within Mir than exists at present because we<br>
>> are beginning to encounter issues like<br>
>> <a href="https://code.launchpad.net/~robertcarr/mir/session-transactions/+merge/175669" target="_blank">https://code.launchpad.net/~robertcarr/mir/session-transactions/+merge/175669</a>.<br>
>><br>
>> As to the suitability of the Qt scenegraph: the compositor, in<br>
>> particular, needs fast response to its queries - so I'm doubtful about<br>
>> implementing them across language boundaries. (I also suspect that it<br>
>> would be hard to satisfy all the functional requirements in Mir this way.)<br>
>><br>
><br>
<br>
</div>Not entirely sure where the notion of a language boundary comes from tbh.<br>
<br>
The idea is simple: We collect all of Mir's internal requirements<br>
towards the scenegraph into interfaces. All internal logic works in<br>
terms of these interfaces and the implementation is injected from the<br>
outside. This could be a default implementation for simple shells<br>
(i.e., not Unity), e.g., the system compositor. Unity then is free to<br>
come up with a simple glue layer that implements Mir's interfaces for<br>
the scenegraph leveraging the existing Qt scenegraph. With that,<br>
surfaces would be available as first class citizens to Unity, and Mir<br>
is happy.<br>
<div class="im"><br>
> Qt's Scenegraph is C++. It offers internal APIs to extend it. I have to<br>
> ask was it ever actually seriously considered? Just claiming it will be<br>
> slow and won't do everything we need isn't much of an argument.<br>
><br>
<br>
</div>I do agree. IIRC, Qt's scenegraph leverages OpenSceneGraph internally,<br>
and that is one fast implementation :)<br>
<div class="im"><br>
> It is a bit late in the day for this discussion, but unless I'm<br>
> mistaken, we've never really had it. I'm aware that changing direction<br>
> at this stage would be tough though.<br>
><br>
> I am concerned about having 2 independent scenegraphs, one for Mir and<br>
> one for shell (Qt). Here are my reasons:<br>
><br>
> 1. Duplication of effort<br>
> Why not use an existing, flexible, well tested and performant<br>
> scenegraph, instead of writing our own from scratch?<br>
><br>
> 2. Synchronicity of 2 scenegraphs<br>
> Unity8 will be animation heavy. Switching windows will involve animating<br>
> both shell elements and mir surfaces. QML will be controlling those<br>
> animations. For each frame am I guaranteed that the Qt scenegraph and<br>
> the Mir scenegraph will be in perfect sync?<br>
><br>
> 3. Complex visual animations<br>
> Right now I wrap Mir's Surface API with a QQuickItem so the surface can<br>
> be animated with QML. The surface is rendered by Mir, but properties of<br>
> that surface can be manipulated by QML, so it is easily animated. This<br>
> works for simple properties like position, opacity... but defining more<br>
> complex transformations (for example a shader effect) on surfaces will<br>
> be very tough to integrate into QML's animation framework.<br>
><br>
<br>
</div>+2, I do share these concerns.<br>
<div class="im"><br>
> One great advantage of QtWayland is that the surface's texture itself is<br>
> pulled into the Qt scenegraph, and wrapped in a QQuickItem, so all<br>
> graphical effects available to QML can be applied to the surface.<br>
><br>
<br>
</div>+1, it will help us to accelerate shell development significantly.<br>
<br>
Agreed, I really like this<br>
<div class="im">> So that's my question: why not emulate QtWayland's approach and use Qt's<br>
> scenegraph and renderer?<br>
><br>
<br>
</div>+1.<br>
<br>
Thanks,<br>
<br>
  Thomas<br>
<div class="HOEnZb"><div class="h5"><br>
> Thanks<br>
> -Gerry<br>
><br>
> --<br>
> Mir-devel mailing list<br>
> <a href="mailto:Mir-devel@lists.ubuntu.com">Mir-devel@lists.ubuntu.com</a><br>
> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/mir-devel</a><br>
<br>
--<br>
Mir-devel mailing list<br>
<a href="mailto:Mir-devel@lists.ubuntu.com">Mir-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/mir-devel</a><br>
</div></div></blockquote></div><br></div>