On Wed, 28 Sep 2011 10:27:33 +0000, jens.bache-wiig wrote: > You have a valid point as I did not expect plots to be a major > performance issue. I don't think anyone can make performance promises at > this point but I would also not expect it to perform as fast as the > current pipeline. On the other hand, being able to draw plot charts, > within Qt Quick was a major reason for adding this API in the first > place.
Obviously you had business charts for nice presentations in mind, but you find completely different type of use cases in the scientific or engineering world. Especially in combination with Qt/Embedded there are many, many applications displaying results from measurements ( often in "realtime" ) - you can find even YouTube videos demonstrating them. But Qwt is also used in GIS applications - think about displaying a spectrogram for the elevation of a whole continent. Qwt is by far the oldest existing addon ( since Qt 1.1 in the 90s) and has become the de-facto standard for plotting in the Qt world over the years. I'm doing this package + all support since many years more or less alone: When plot charts were really one of the major reasons for introducing Qt Quick I'm more than surprised, that nobody ever contacted me to find out what the real world use cases for a plotting widget are. Anyway ... > I also get the feeling that embedding Qt Quick inside Widgets might not > be as straight forward as I thought, so I second Samuel's suggestion > that just using your existing drawing code with a QImage might be the > way to go. The plot canvas has its own backing store ( a QPixmap ) so - ignoring, that I might loose any hardware acceleration - I could implement this easily. But there are known use cases ( f.e. the oscilloscope ), where this buffering needs to be turned off to get the required refresh rates. So when I get it right this all means that if an application needs a Qwt plot with certain performance requirements it needs the QPainter API and therefore can't use Qt-Quick in the complete application - at least as long as embedding a QWidget into a QML application is not supported. For all other type of plots I could offer a second path, where the plot is rendered via QPainter/C++ and QImage/QSGItem to something Qt Quick compatible and the application could make use of Qt Quick ? Isn't it possible to have an C++ API for the scene graph too - in the end isn't it a problem of the API ( QML ) only and has nothing to do with the new graphics pipeline ? And what about the generation of documents ( mostly PDF ), what is one of the key features of any good plotting library. Is this something I could do with QML too or do I need to keep the QPainter based render code because of this anyway ? Uwe _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
