Application freeze on QGraphicsItem.setRotation

Hello,

To be honest I have asked this elsewhere, but to no avail and it is a Qt-related question so I feel it should really have come here. I will stop and redirect the (unstarted) other thread if anything helpful is made public here.

Context: Two QGraphicsView+Scene pairs in two different windows and a simple QGraphicsItem hierarchy.
Problem: Application freezes on self.setRotation call from QGraphicsItem.paint methods when items visible on both views.
Example: Download the small tarball and start the she-banged file.
Remarks:

• if you comment out both culprit setRotations (lines 66 and 95 in the GUI.graphics.contact module, marked with "#FIXME"), you get a running program where you can wheel in/out and pan the scene with no trouble.
• The freeze also disappears if you comment out the new window creation (l. 17 in GUI.main).
• No freeze if the items are out of the view.

Tried: Moving the setRotations out of the paint methods and setting from the parentItem, but still freezes, therefore not a problem of calling from the paint method.

Of course you may know exactly what is wrong with my code. But otherwise, what could possibly make a .setRotation(constant) call to freeze a program?

Thank you for any help you may provide, or for your time reading.
Michael.

Are you sure the program freezes?

Sounds a bit like you would get into an endless loop.
Something like
painting -> setting different rotation -> need update -> painting -> set different rotation .....

Cheers,
_

Hmm. Good thought... But why only when a second window opens? And then does it mean setRotations (and in such case I assume all transformations and setPos) are always to be avoided in paint methods? I have never seen that advice anywhere around. Also as I said, there is no improvement when I pull the setRotation out of the paint method.

I would never change anything inside a paint method, especially nothing that could influence what is to be painted.

How do you determine the rotation value?
Maybe you include some values in the calculation that change when you rotate and that leads to the "update loop"?

Cheers,
_

Quote:

---

Originally Posted by anda_skoa

I would never change anything inside a paint method, especially nothing that could influence what is to be painted.

---

Point taken; I will eventually move all side effect out of paint(), but as I said this did not solve the problem when I tried.

Quote:

---

Originally Posted by anda_skoa

How do you determine the rotation value? Maybe you include some values in the calculation that change when you rotate and that leads to the "update loop"?

---

I have posted a link to a reduced source code sample that produces the problem, and given the line numbers so you can inspect better than I can ever describe. In this version of contact.py, both problematic setRotations have constant arguments, and no other side effects exist.

Also another thought, I have had update loops when I was still figuring how QGraphics worked, and they always led to a clearly reported stack overflow ("maximum recursion depth" or such). What you are suggesting is rather some paint method exiting and re-entering immediately, which to me is unlikely.

Quote:

---

Originally Posted by mickybadia

Also another thought, I have had update loops when I was still figuring how QGraphics worked, and they always led to a clearly reported stack overflow ("maximum recursion depth" or such). What you are suggesting is rather some paint method exiting and re-entering immediately, which to me is unlikely.

---

Well, the update loop was an idea of what could be the effect you are seeing.
It doesn't have to lead to a call stack overflow, not even event processing is involved which can easily decouple one loop iteration from the next.

So you have moved setRotation to the place where you create the SpeedLineItem and the problem still shows?

I see you have log output in the paint method. Does it repeatedly get repainted despite nothing in the scene changes?

Btw, shouldn't all views show the same scene?

Cheers,
_

Solved! And you were right about it. I still do not understand why everything worked fine for months until I created a second scene sharing nothing with the first, which led me on the wrong track for diagnosis.

Quote:

---

Originally Posted by anda_skoa

So you have moved setRotation to the place where you create the SpeedLineItem and the problem still shows?

---

In fact for this test I had moved setRotation out of the self.paint and into the parentItem's paint where nothing (else) was done. It did not solve anything but your looping idea could come from that too. So I moved almost everything out of the paints and into a new updateItem where I have placed all the setPos and setRotation methods. That worked.

So let us all benefit from my wasted time: no setPos/Rots in paints!

Quote:

---

Originally Posted by anda_skoa

Btw, shouldn't all views show the same scene?

---

I was actually hoping I could at some point, but the user can turn on/off different things on his different screens, which parts from the model/view idea, though most items are shared indeed.

Quote:

---

Originally Posted by mickybadia

In fact for this test I had moved setRotation out of the self.paint and into the parentItem's paint where nothing (else) was done. It did not solve anything but your looping idea could come from that too.

---

Yes, the setRotation() was still inside the paint path.

Quote:

---

Originally Posted by mickybadia

So let us all benefit from my wasted time: no setPos/Rots in paints!

---

In general I would consider paint() and similar methods to be "const", even if their method signatures are not.
The only thing these would probably change are cached drawings or values determined through drawing needed elsewhere.

Cheers,
_