On Wed, 18 Jul 2012 13:28:02 ext Lincoln Ramsay wrote: > On 07/18/2012 05:17 AM, ext Andreas Aardal Hanssen wrote: > > My point is simply that Qt 5 is best served with a painting backend for > > QML 2 that can support non-OpenGL technologies. > > I don't want to start a flame war here but I always wondered why > "QtQuick 2" had to mean SceneGraph/OpenGL and why the new/changed QML > types couldn't be separate to the "display engine".
QtQuick 2 has to mean SceneGraph/OpenGL because the QtQuick module provides the visual primitives. It is the display/user-input engine, thus QQuickItems need to run on a QQuickWindow and QDeclarativeItems need to run in a QGraphicsScene. QML 2, now split out into the QtQml module, is separate to the display engine. If you're more thinking widget style of a single "Rectangle" that chooses SGRect or GVRect behind the scenes, that's not how QML items are abstracted. QtQuick provides graphical primitives which you use to create your widgets, QtQuick 2.0's Rectangle is the SGRect and QtQuick 1.0's Rectangle is the GVRect. As people have noticed, we haven't done a great job in making it easy to choose one behind the scenes :( . But the future is clearly 3D GL in the general case, so long as niche 2D CPU applications are supported somehow the 3D display engine should be the default and supported as well as possible. > Obviously from a C++ perspective you have to know which engine you're > using but the QML environment is insulated from the display engine, right? > > Maybe it's because the QML types are implemented in C++ that makes it > difficult to support them across display engines... The display engines are radically different, and we don't have some QGraphicsProxySceneGraph element to go between them. As for the QML environment, not the different display engines, implementation issues are the reason why QtQuick 1.0 "can't" be run in a QQmlEngine (I say "can't" because maybe they can, I've never tried). There have been changes to the engine and language due to V8 integration, and although these are supposed to be much more compatible there are behavioural changes. The QDeclarativeEngine is left around for QtQuick 1 because that way your QtQuick 1 applications can use the old engine for less chance of behavioural regressions. Not because QtQuick 1 is fundamentally incompatible with QQmlEngine. Theoretically you can have two different windows running the two different display engines but sharing one QML engine - I've just never tried and I doubt it would be a high priority bug if that didn't work ;) . -- Alan Alpert _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development