Penalty of using QGraphicsObject vs QGraphicsItem?

问题:

I currently have a hierarchy of items based off of QGraphicsItem.

I want to move to QGraphicsObject instead so that I can put properties on my items. I will not be making use of signals/slots or any other features of QObject.

I'm told that you shouldn't derive from QObject because it's "heavy" and "slow".

To test the impact, I derive from QGraphicsObject, add a couple properties to my items, and look at the memory usage of the running app. I create 1000 items using both flavors and I don't notice anything more than 10k more memory usage.

Since all I am adding on to my items are properties, is it safe to say that QObject only adds weight if you are using signals/slots?

回答1:

I think it depends on what you mean by weight. If you're not worried about the additional memory required nor all the extra methods and things that come with QObject, which sound like baggage in your case, then yes.

But, if all you need is a way to store some additional information, why not subclass QGraphicsItem and add a method or two that allow you to store the necessary data? By doing so, I think you'll better communicate the intent of your code, which seems more important than all of the above.

回答2:

@Mason Chang: That makes sense, but if the emits of signals that happen when using QGraphicsObject is what makes QGraphicsObjects slower than QGraphicsItems, then you can avoid this by inheriting from QObject and QGraphicsItem instead of using QGraphicsObject. That way you can define signals and slots but you don't get the overhead of automatically emitted signals you have no interest in.

Does this make sense and provide a good performing middle ground between QGraphicsObject and QGraphicsItem?

edit: made a new question for this that might be a bit more clarifying

回答3:

How about performance? There is extra cost in QGraphicsObject when calling setX/setY, and so on. You can go to QGraphicsItemPrivate::setPosHelper and find more details.