Canvas vs custom QQuickItem
-
Hello everyone,
I am developing some application that will be executed on embedded/mobile device. I look for a very fluid UI, so I choose QtQuick2 and QML for building UI, and keep C++ for backend tasks.
At this point, I need to add some (really often discussed topic here) charts view in my application. And I have many questions about the correct and modern way to do that.
I say modern because I know that some library as Digia Charts use the Graphics View framework to achieve charting, and even it was made for Qt4, we can still use this work in QML. Do you think that for a new application, with these deployment targets in mind, this part of framework could be enough?
In pure QML, I could use Canvas API and make all rendering process in Javascript. Well, I am really more familiar with plain C++ than JS, but more than that I have some concerns about performance and interaction possibilities with nodes in my chart. Am I totally wrong to be not attracted by this way?
Another question raised when I was looking into QtQuick 2 documentation. I just imagine a way to use QtQuickItem as I would use a QGraphicsItem in Qt4. Painting custom items with scenegraph API is a bit low-level for me, but I read about QQuickPaintedItem and its QPainter API. Well, QQuickPaintedItem documentation expresses that it should be only use for porting Graphics View code..so I am a bit confused about a correct usage of it.
It would be really nice if someone could enlighten me about this subject, and help me to make the best choice. Thanks in advance for your time :)
-
[quote author="jb2a" date="1380043070"]ell, QQuickPaintedItem documentation expresses that it should be only use for porting Graphics View code..so I am a bit confused about a correct usage of it.[/quote]
This is a bug in the documentation, and I think it has already been fixed (should be ready in Qt 5.2).
You can safely use QQuickPaintedItem in your code, in fact it can even be faster than QQuickItem in some use cases.
