[Development] QtSC: Scene Graph discussion
Gunnar.Sletta at digia.com
Fri Aug 2 09:39:23 CEST 2013
On Aug 1, 2013, at 10:59 AM, Laszlo Papp <lpapp at kde.org> wrote:
> On Thu, Aug 1, 2013 at 8:17 AM, Sletta Gunnar <Gunnar.Sletta at digia.com> wrote:
> Indeed, the proposed patch created an new library (which was only built when manually cd'ing into src/scenegraph and building it there) which would not have been usable together with Qt Quick (until Qt 6, that is).
> I would be personally more than happy for scene graph to become compact, i.e. qml and qtquick being a separate layer. I do not mind in which repository this separation happens in; that is just details for me, not a technology show stopper. That brings me to my question: although I was attending to the session, have you discussed this out of the session with others?
Have I discussed it outside, yes. I posted a mail to the mailing list a month or so back with little response and I've discussed it with a couple of people directly. The topic usually ends on: what is the benefit of using the stripped-down SG API, without text support, when you could do much the same and probably do something even faster, dedicated for your purpose using raw OpenGL. The new renderer, I've been working on will make it a bit harder to beat, but for a specific usecase, raw OpenGL will always be better.
> Do you have any plans to get into 5.2?
The change currently does two things in one go.
1. It moves code around a bit under src/quick/scenegraph so that there is a clean separation between the "Core SG API" and the "Qt Quick use of the SG API". src/quick/scenegraph now only contains Core API and quick related stuff goes under src/quick/quickscenegraph. This library would be provided with no warranty or support what-so-ever.
2. It adds a src/scenegraph/scenegraph.pro and some additions to the toplevel sync.profile which makes it possible to build do cd src/scenegaph; qmake; make to make a new stand-alone (and non-compatible with libQtQuick) libQtSceneGraph.
3. It adds an example on how to use it stand alone
4. It adds an autotest that tries to build it so that we get CI coverage on that changes to QtQuick does not accidentally break the optional standalone module.
I think 1. makes sense regardless, because it makes the codebase cleaner. The session kinda concluded that 2-4 are not needed. Then again, if 1 is in place, pulling that into its own library which can be used stand-alone is pretty simple, so the presence of 2-4 is less pressing.
More information about the Development