使用QGraphicsObject
这被认为是缓慢的.根据this answer的stackoverflow QGraphicsObjects由于它们的实现而缓慢.当我查看QGraphicsObjects的源代码时,我可以看到根据对对象所做的更改发出大量信号.对我来说,这似乎是一个合理的论据,为什么QGraphicsObjects是慢的,但我认为这个性能命中(如果真的是一个)可以避免的第二个解决方案.
从QObject和QGraphicsItem继承.
当构造一个从QObject和QGraphicsItem继承的类似乎可以让您获得QGraphicsObject最有趣的功能,减去性能命中：您可以在类中定义插槽并发出信号,但不能继承QGraphicsObject的默认实现会不断发出可能不感兴趣的变化的信号.您现在可以发出信号,但不必担心发生信号的事情不在意(x值表示更改在QGraphicsObject中发出信号,不在这个解决方案).
我的问题摘要
QGraphicsObject是否比QGraphicsItems慢？
>如果是这样,那是因为实现发出信号(并且发射信号是一个
大的表现打击)？
>如果是这样,第二个解决方案(多重继承)是否避免了这种惩罚？
解决方法
Are QGraphicsObjects really slower
than QGraphicsItems?
是.你的分析是正确的. QGraphicsObjects由于它们执行的信号而较慢.它们还具有更大的内存开销,因为它们继承自QObject,如果正在创建许多QGraphicsObject,这可能会显着影响性能.
If they are,is it because the
implementation emits signals (and
emitting signals is a big performance
hit)?
是的,如果使用项目的方式导致过多的信号.然而,发射信号可能不如其他操作那么昂贵.在the talk “Qt GraphicsView in Depth”年,Alexis Menard表示对itemChange的调用速度很慢,有时更好地直接收听更改. QGraphicsItems和QGraphicsObjects都将使用itemChange处罚.
And if so,does the second solution
(multiple inheritance) avoid this
penalty?
是.通过继承QGraphicsItem和QObject可以避免一些不必要的信令,并且仅发送需要的信号.当然,QObject的内存开销仍然会发生.
