tiftof
7th February 2011, 15:15
I want to add signals/slots to a QGraphicsItem so I can reach QGraphicsItemObjects from another thread. There are two options that I know of: use QGraphicsObject or inherit from QObject and QGraphicsItem.
Using QGraphicsObject
This is assumed to be slow. According to this answer (http://stackoverflow.com/questions/2292072/penalty-of-using-qgraphicsobject-vs-qgraphicsitem/2661673#2661673) on stackoverflow QGraphicsObjects are slow because of their implementation. When I look in the source of QGraphicsObjects I can see a lot of signals being emitted according to changes made to the object. To me this seems a plausible argument for why QGraphicsObjects are slow, but I think this performance hit (if it really is one) can be avoided by the second solution.
Inheriting from QObject and QGraphicsItem.
When constructing a class that inherits from QObject and QGraphicsItem it seems that you get the most interesting feature of QGraphicsObject minus the performance hit: you are able to define slots and emit signals in your class but you don't inherit the default implementation of QGraphicsObject that would constantly emit signals on changes you might not be interested in. You are now able to emit signals but don't have to worry about signals being emitted for things you don't care about (x value that changes emits a signal in QGraphicsObject but not in this solution).
Summary of my question
Are QGraphicsObjects really slower than QGraphicsItems?
If they are, is it because the implementation emits signals (and emitting signals is a
big performance hit)?
And if so, does the second solution (multiple inheritance) avoid this penalty?
Using QGraphicsObject
This is assumed to be slow. According to this answer (http://stackoverflow.com/questions/2292072/penalty-of-using-qgraphicsobject-vs-qgraphicsitem/2661673#2661673) on stackoverflow QGraphicsObjects are slow because of their implementation. When I look in the source of QGraphicsObjects I can see a lot of signals being emitted according to changes made to the object. To me this seems a plausible argument for why QGraphicsObjects are slow, but I think this performance hit (if it really is one) can be avoided by the second solution.
Inheriting from QObject and QGraphicsItem.
When constructing a class that inherits from QObject and QGraphicsItem it seems that you get the most interesting feature of QGraphicsObject minus the performance hit: you are able to define slots and emit signals in your class but you don't inherit the default implementation of QGraphicsObject that would constantly emit signals on changes you might not be interested in. You are now able to emit signals but don't have to worry about signals being emitted for things you don't care about (x value that changes emits a signal in QGraphicsObject but not in this solution).
Summary of my question
Are QGraphicsObjects really slower than QGraphicsItems?
If they are, is it because the implementation emits signals (and emitting signals is a
big performance hit)?
And if so, does the second solution (multiple inheritance) avoid this penalty?