[Development] Suggestion on QML portability

[Alan Alpert]

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