> Not to mention the performance wreck it will turn into... > > QGraphicsProxyWidget was horrible for performance if you had more than one or > two. One reason for this is that the styles need to be rendered with raster > (or possibly native) paint engines because of its ease of integration with > native style APIs and its superior quality compared to the OpenGL engine. > This results in each widget having to be uploaded as a texture afterwards, so > whenever something changes, we get rendering hickups.
The other problem is all the painting setup that happens behind the scenes inside QWidget::render() before actually getting to the QWidget::paintEvent() (http://labs.qt.nokia.com/2009/12/16/qt-graphics-and-performance-an-overview/). That also costs quite a bit in many cases.. > There are good usecases for such a class, embedding one or two toplevel > widgets into an otherwise QML scene would probably be ok for performance. > Embedding a proxied QPushButton for every button in the keyboard not so > much... > > I see a people having a certain technology, say charting, which is > encapsulated in a QWidget, and it should be possible to integrate those > technologies into QtQuick 2.0. Just make it really hard so it is not the > obvious choice :) > cheers, > Gunnar _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
