turn off collision detection?

**wysota** · 3rd November 2008, 19:23

Originally Posted by Deacon

Hi wysota, thanks for your response.

> boundingRect() is necessary for the architecture to know which items to repaint when a
> particular area needs refreshing.

I already know which QGItems I need to repaint, and I've tried to force to update just the boundingRect of these items, through QGraphicsItem.update(QRect) and QGraphicsScene.update(QRect) calls. But I still encounter an onslaught of unnecessary boundingRect() calls, that kill my performance.

The fact that you update some part of the view doesn't mean all items present there get repainted.That's where the bounding rect comes in. The view tracks regions that have been changed and repaints only those items that intersect the region. If you disable automatic updates, you have to do all the updating stuff yourself (including calling the painting routine of each item you want painted).

If you move items often, it might be good for you to disable indexing, maybe that is what is degrading your performance.

> It also defines a local coordinate system for each item,
> so unless you want to strip away everything the graphics view gives you (I mean all
> benefits), it will be hard to get rid of boundingRect() and collision detection.

So each QGraphicsItem.paint() call requires a boundingRect() call.

No. But anyway it's good to cache the bounding rect instead of calculating it during every call to this method.

I can dig that because I can tell the QGraphicsView framework which areas to repaint. Going back to my .update() use above, I'm still not clear why the .update(QRect) function can not just redefine the local coordinate system starting at the .x() .y() of the QRect I pass to .update().

The local coordinate system has nothing to do with the area you repaint.

Can I just repaint that QRect another way?

Yes, you can call the paint routine of each item occupying that area yourself. Before doing that you'll have to provide necessary transformations for the painter to reflect the proper coordinate system.

> On the other
> hand if you want to get rid of them, maybe you shouldn't use graphics view at all?

I disagree completely. There's lots of great stuff under the hood, that Indexing seems to kill the performance of when more than a few tens of thousands of QGraphicsItems are present in the scene. So an option is offered to turn indexing off, but no option to reimplement where to repaint? It just seems like not a very big step to uncover some real performance flexibility.

What great stuff are we talking about? Most "great stuff" in graphics view concerns determining what to repaint

What exactly is your usecase? How come do you think you know better what to repaint than the GV architecture? Could you explain this?

**Deacon** · 4th November 2008, 00:50

Originally Posted by wysota

The fact that you update some part of the view doesn't mean all items present there get repainted.That's where the bounding rect comes in. The view tracks regions that have been changed and repaints only those items that intersect the region. If you disable automatic updates, you have to do all the updating stuff yourself (including calling the painting routine of each item you want painted).

If you move items often, it might be good for you to disable indexing, maybe that is what is degrading your performance.

So I have to actually call the paint() function, and not rely on .update() or .invalidate() because all that stuff is turned off. Ok.

Originally Posted by wysota

Yes, you can call the paint routine of each item occupying that area yourself. Before doing that you'll have to provide necessary transformations for the painter to reflect the proper coordinate system.

What exactly is your usecase? How come do you think you know better what to repaint than the GV architecture? Could you explain this?

Sure, its a panel of tiles that wrap the window with window resizes. I could have gotten away with the QTableView but I was worried that it's not quite as flexible as the GV system.

**Deacon** · 23rd December 2008, 00:31

[Weeks Later...]

[QUOTE=Deacon;84597] So I have to actually call the paint() function, and not rely on .update() or .invalidate() because all that stuff is turned off. Ok.

Qt 4 issues warnings when the paint function is called outside of a paintEvent, so this approach did not work for me and I've found a better way.

I've recently discovered two rendering commands that DO work even when setViewportUpdateMode .( QtGui.QGraphicsView. NoViewportUpdate ) has been called; qgrapics_view_object.viewport().update() and .viewport().repaint(x, y, w, h)... I've so far found these to offer a very efficient alternative to the build-in paint event handling for some must-be-immediate events. This applies mostly because of my somewhat unusual situation where I can (and must) be able to recalculate those numbers pretty quickly.

Just thought I'd share back a little.

**wysota** · 23rd December 2008, 00:43

Correct me if I'm wrong, but calling update() or repaint() on the graphics view's viewport is intercepted by the graphics view using an event filter and redirected to the usual graphics view update mechanism...

**Deacon** · 23rd December 2008, 18:05

Originally Posted by wysota

Correct me if I'm wrong, but calling update() or repaint() on the graphics view's viewport is intercepted by the graphics view using an event filter and redirected to the usual graphics view update mechanism...

seems like GV.viewport().update() reroutes back to the usual update system. I just was not previously aware of anything that renders when NoViewportUpdates is on. Only under the NoViewportUpdate setting does my CPU to not grind away at 50% the whole time my app is running.

.repaint() I'm pretty sure does not go through .update().

in __init__():

self.setViewportUpdateMode(QtGui.QGraphicsView.NoV iewportUpdate)

then in my QGraphicsItem:

def updateNow(self):
b = self.bRect
self.parent.viewport().repaint(b.x(), b.y(), b.width(), b.height())

works. So I guess its not going through the normal update() mechanism.

Is this not the way its supposed to be?

Deacon

**wysota** · 30th December 2008, 11:06

The only difference between update() and repaint() should be the former uses QCoreApplication::postEvent() to post a paint event and the latter uses QCoreApplication::sendEvent() to execute the same event without going through the event queue. So the result in both cases should be identical with the only difference that update() makes a deferred call and repaint() forces an immediate redraw.