Linked by vivainio on Thu 14th Oct 2010 11:31 UTC
KDE In his lengthy and interesting blog post covering the future of Plasma, KDE's Aaron Seigo proposes Qt Quick and QML (a declarative language that embeds JavaScript) as replacement of the Graphics View architecture currently used by Plasma. This holds a promise of massive speedups and cheap effects as all paint operations become candidates for OpenGL acceleration, contrary to the aging Graphics View architecture that is still stuck with various inefficiencies caused by the underlying QPainter approach. Expressiveness and easy programmability of QML is a nice bonus, of course.
Thread beginning with comment 445043
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: ...
by vaette on Thu 14th Oct 2010 13:27 UTC in reply to "..."
vaette
Member since:
2008-08-09

By the sound of things the drawing models will live side-by-side for the foreseeable future, so your worry is probably misplaced.

Better performance at a base level is often helpful to be able to write more robust code too, since less hacking to make things perform usually makes things easier to handle.

Reply Parent Score: 7

RE[2]: ...
by Hiev on Thu 14th Oct 2010 13:30 in reply to "RE: ..."
Hiev Member since:
2005-09-27

Those same sentenses were told when QGraphicsWidget was released, now result that QML is the one. And after that who knows, Im glad you are so optimistic, im not.

Reply Parent Score: 2

RE[3]: ...
by aseigo on Thu 14th Oct 2010 13:46 in reply to "RE[2]: ..."
aseigo Member since:
2005-07-06

Those same sentenses were told when QGraphicsWidget was released, now result that QML is the one. And after that who knows, Im glad you are so optimistic, im not.


first off, we're already moving to QML. some parts started on QML (e.g. the Plasma Mobile shell and some of the mobile specific components). QML renders right now on top of QGraphicsScene, so it hasn't been a shift for us in that respect. the real shift is moving away from QGraphicsScene to QSceneGraph, which in turn will require (in all practicality) all Plasma components to use QML (right now we can pick and choose which do). but that's a decision that is still 1-2 years out, and in the meantime we continue to work on what we have done right now.

it's also useful to consider QGraphicsScene's path thus far: it absolutely was a large improvement over what we had prior to it, and due to its design (and how we used it in Plasma) moving to QSceneGraph as well as QML is relatively straightforward. it is nothing like what we had to go through to get a scene based component system (aka Plasma) together in the first place.

i don't know if QML will be the "final" answer in the long term (5-10 years), but it is a move in the right direction and provides us a way to get more out of what we are already doing.

as a comparison, QGraphicsScene debuted 4 years ago and was in development for probably a full year before that. it'll still be what we're using, with improvements being made to it, for at least the next 1-2 years. so if Plasma does move to QSceneGraph, then we will have had 5+ years of service by QGraphicsScene and the benefits it brought us.

i'd expect at least that (if not more, as it embodies lessons learned from QGraphicsScene) from QSceneGraph.

given that the migration path to QSceneGraph is fairly evident at this point and can be done pretty smoothly for us, i think it's a reasonable situation.

and at the end of the day, the vast majority of API and code in plasma itself will remain untouched due to clean separations between visualization and business logic.

Reply Parent Score: 12