[PyQt] Re: PyQt4 and threading

[Ole Streicher]

Hi Andreas,

Andreas Pakulat <apaku at gmx.de> writes:
> On 15.10.09 09:22:03, Ole Streicher wrote:
>> >>         item.setBrush(QtGui.Brush(QtGui.QColor(...)))
>> Jason H <scorp1us at 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