将信号/槽(QObject)添加到QGraphicsItem:性能命中？

Question

我想在QGraphicsItem中添加信号/槽,这样我就可以从另一个线程到达QGraphicsItemObjects.我知道有两个选项:使用QGraphicsObject或从QObject和QGraphicsItem继承.

使用QGraphicsObject

这被认为是缓慢的.根据stackoverflow 上的这个答案,QGraphicsObjects由于它们的实现而很慢.当我查看QGraphicsObjects的源代码时,我可以看到根据对象所做的更改发出了很多信号.对我来说,这似乎是QGraphicsObjects缓慢的原因,但我认为第二种解决方案可以避免这种性能上升(如果真的是一次).

继承自QObject和QGraphicsItem.

当构造一个继承自QObject和QGraphicsItem的类时,你似乎得到了QGraphicsObject最有趣的功能减去性能命中:你可以在你的类中定义槽和发出信号,但是你不能继承QGraphicsObject的默认实现.你会不断发出你可能不感兴趣的变化的信号.你现在能够发出信号,但不必担心你不关心的事情会发出信号(x值变化会在QGraphicsObject中发出信号但是不在这个解决方案中).

我的问题摘要

• QGraphicsObjects真的比QGraphicsItems慢吗？
• 如果它们是,是因为实现发出信号(并且发射信号是一个很大的性能损失)？
• 如果是这样,第二个解决方案(多重继承)是否会避免这种惩罚？

Answer 1

该线程提出了另一种选择:创建一个QObject子类,代表您的QGraphicsItems发出信号.

如果你有许多QGraphicsItem可以共享一个QObject,那么这将比每个QGraphicsItem继承QObject更轻量级.

Answer 2

QGraphicsObjects真的比QGraphicsItems慢吗？

是.你的分析是正确的.由于它们执行的信令,QGraphicsObjects较慢.它们还具有更大的内存开销,因为它们继承自QObject,如果正在创建许多QGraphicsObjects,这可能会显着影响性能.

如果它们是,是因为实现发出信号(并且发射信号是一个很大的性能损失)？

是的,如果项目的使用方式导致过多的信号.然而,发射信号可能不像其他操作那样昂贵.在演讲"Qt GraphicsView in Depth"中,Alexis Menard说对itemChange的调用很慢,有时候直接听取更改会更好.QGraphicsItems和QGraphicsObjects都会因使用itemChange而受到惩罚.

如果是这样,第二个解决方案(多重继承)是否会避免这种惩罚？

是.通过继承QGraphicsItem和QObject并且仅发出所需信号,可以避免一些不必要的信令.当然,QObject的内存开销仍然会发生.