CPU churning with .update() (also scrolling with NoViewPortUpdate)

[Deacon]

Hi,

I load several thousand QGraphicsItems into a QGraphicsView and am having a serious problem with the update system. Once loaded, my cpu will churn away between 60-100%. I've figured out that this is mostly from bounding rect calls, and am not sure how to get rid of them.

Is this a common problem? I haven't seen any other threads about a rampaging CPU when the program is idle, and am not certain where to look in my code for this.

FYI I have indexing turned off if this is maybe related.

On a very closely related note, If I turn off viewport updates:

self.setViewportUpdateMode(QtGui.QGraphicsView.NoV iewportUpdate)

this gets rid of the churning, and I use QGI.repaint() to render my hover highlighting, but there are two new problems (so far).

1 my hover highlight is rendered as semi-transparent, other painter stuff is rendered semi-transparent as well.

Any advice on this? I have no clue as to why the transparency changes with the internal update system off.

2 I lose scrolling. I can repair the scrolling by overriding scrollContentsBy and including a viewport().update() call, but my scrolling becomes way jumpy compared to when viewport updates are turned on.

Any advice on how the update system makes QGV scrolling so smooth?

Thanks,

Deacon

[wysota]

If you do any interaction with items on the scene, don't turn off indexing. NoViewportUpdate is probably not a solution for you as well. Are your items animating or static?

[Deacon]

If you do any interaction with items on the scene, don't turn off indexing. NoViewportUpdate is probably not a solution for you as well. Are your items animating or static?

Yah I wish I could use indexing, but the QGraphicsItem objects are HIGHLY dynamic with every window resize, plus they can be grabbed and they move and they bump into each other (should handle up to 500K items or so - right now it does 10K). They're arranged in a table, so its pretty easy to reimplement .itemAt, and indexing removal has not really been an issue (my reimplementation is slightly faster than the built-in). It is mostly the viewport update system that has been not cooperating.

[Deacon]

By the way, wysota, these issues are related to our prior discussion here:

http://www.qtcentre.org/forum/f-qt-p...html#post84482

[wysota]

If items are arranged into a table then updating the index tree should be very cheap so disabling indexing should yield little improvement in this situation and it is really worth having that index. You might also want to disable indexing only temporarily. To upgrade performance, if you don't do any clicking or hovering at some moment, you can disable the interactive flag on the view, it should speed up things somewhat.

At some point if you disable most of graphics view's features it becomes a weakness to use it, not an advantage, so rethink the idea of using it at all.

[Deacon]

Yes, I had been thinking about using QWidget, but the fact of the matter is that there are only two problems I've found after removing the posted updating system. They are those described here, where my scroll speed is limited by the .veiwport().update() calls (where it should be .move or .translate or something), and there's some wierd semi-transparency thing going on with some of the paint events. My implementation is otherwise competitive with the built-in, with slightly different balancing to accomodate my particular user needs (the repaint for faster hover events for instance). But its not like I'm tracking sprites or anything ferociously complex...

If I were to move to a QWidget, this would break the Graphics Framework conceptual model that I'm trying to maintain, no matter how much I hack the internals, if that makes sense.