Hi Andreas, Andreas Pakulat <ap...@gmx.de> writes: > On 15.10.09 09:22:03, Ole Streicher wrote: >> >> item.setBrush(QtGui.Brush(QtGui.QColor(...))) >> Jason H <scorp...@yahoo.com> writes: >> > GUI operations can only be done in the main thread. >> Is setting the brusch of a QGraphicsRectItem a GUI operation? > Possibly, the scene.update() is definetly going to trigger GUI > operations.
But, the crashes are *not* in the scene.update(), but in the item.setBrush() call. This is funny, since QGraphicsRectItem does not even dervive from QObject and is therefore not part of the Qt object hierarchy. > I don't think updating the brush of 100.000 is going to take multiple > seconds. Qt won't redraw after each change, but only once you return to the > event loop and then the brushes of all items have already changed. The point is possibly not Qt itself but the calling from PyQt: at every call there are several transitions between Python and Qt (creating QColor, getting QColor back to Python, creating QBrush, getting it back to python, calling setBrush()). The mentioned code item.setBrush(QtGui.Brush(QtGui.QColor(...))) is definitely slower than item.brush().color().setRgb(...) The latter also does not cause the mentioned crashes, but it does not work for Qt 4.5.2 anymore (why? it worked for 4.5.0). > However if it really is too slow, you can simply split up the work into > chunks and let the event loop run in between so the GUI keeps responsive. > One way to achieve this is by using a QTimer which fires regularly and then > work on a chunk in the connected slot. That sounds like creating my own "cooperative" multitasking structure which sounds very complicated and errornous (think of Windows 3.1 which already used this model). Regards Ole _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt