[Development] Notes from the QWidget session

[gunnar.sletta at nokia.com]

> 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