6

在 Mint Linux 12 上使用 Qt4.8，我实现了一个包含QTableView显示模型内容的简单窗口。模型数据不断更新（日志消息），并dataChanged()定期发出信号（即每 100 毫秒）。

我看到的问题是桌子上的视觉更新口吃。

我在计算 -type 事件的窗口上安装了一个事件过滤器updateRequest，它应该触发一个小部件重绘（也在子小部件上，即tableView）。它们之间的平均时间约为 170 毫秒，标准偏差约为 90 毫秒（我猜这是相当大的）。然而，感知到的视觉更新率仅为每秒两到三倍，我想知道为什么。似乎并非所有updateRequest事件都会触发小部件重绘或窗口系统会吞噬视觉更新。

作为第二个测试，我强制窗口通过调用repaint或update每 100 毫秒更新一次。使用repaint，我看到 - 类型的事件相应增加，updateRequest而差距的标准偏差减小；，update数量没有增加。然而，在这两种情况下，感知更新率都只有适度的增加。

另外：有没有一种很好的方法来衡量一个小部件实际上真正重绘的频率而不必重载其paintEvent处理程序？也许来自QTest?

更新：我扩展了我的事件过滤器来捕获paintEvent-type 事件。updateRequest与 > 1000 个类型的事件相比，这些事件只有一位数。

4

2 回答 2

1

您应该检测事件调度程序aboutToBlock()和awake()信号，并使用QElapsedTimer. 当前线程的事件分派器实例由 static 返回QAbstractEventDispatcher::instance()。

如果事件循环在你的时间测量窗口的一小部分休眠，这意味着 GUI 线程中发生了太多事情。您可以记录事件循环在最后一秒内休眠了多长时间。如果低于 10%，您可能会遇到更新缓慢之类的情况。请记住，更新事件与Qt::LowEventPriority. 它们将被标准排队信号和几乎所有其他事件抢占。

于 2012-06-12T16:31:54.380 回答
0

QApplication::compressEventQEvent::UpdateRequest如果已经有一个未处理，则丢弃。因此，如果事件被丢弃，即使 repaint(s) 也可以立即返回而无需绘制。您可以检查，如果您的updateRequest事件被覆盖丢弃compressEvent。

于 2012-06-12T13:46:45.700 回答