在Mint Linux 12上使用Qt4.8，我实现了一个包含QTableView的简单窗口来显示模型的内容。模型数据不断更新（日志消息），dataChanged()信号定期发出（即每100毫秒）。
我看到的问题是桌面上的视觉更新。
我在窗口上安装了一个事件过滤器，用于计算updateRequest - 类型事件，这应该触发窗口小部件重绘（也适用于子窗口小部件，即tableView）。它们之间的平均时间约为170毫秒，标准偏差约为90毫秒（我猜这是相当大的）。然而，感知的视觉更新率仅为每秒两到三次，我想知道为什么。似乎并非所有updateRequest事件都会触发窗口小部件重绘或窗口系统吞下视觉更新。
作为第二次测试，我强制窗口每隔100ms调用repaint或update来更新自己。使用repaint，我看到updateRequest类型事件的相应增加和间隙标准差的减少;使用update，数字没有增加。但是，两种情况下感知更新率只有适度增加。
另外：有没有一种很好的方法可以测量窗口小部件实际重新绘制的频率，而不必重载其paintEvent处理程序？也许来自QTest的东西？
更新：我扩展了我的事件过滤器以捕获paintEvent - 类型事件。只有一位数的那些与＆gt; 1000 updateRequest - 类型的事件。
答案 0 :(得分：1)
您应该检测事件调度员的aboutToBlock()和awake()信号，并使用QElapsedTimer衡量他们之间的时间。静态QAbstractEventDispatcher::instance()返回当前线程的事件调度程序实例。
如果事件循环只占你时间测量窗口的一小部分，那就意味着GUI线程中有太多东西在进行。您可以计算事件循环睡眠的时间，例如，在最后一秒。如果它低于10％，你可以期待缓慢的更新和诸如此类的东西。请记住，更新事件排队Qt::LowEventPriority。它们将被标准排队信号和几乎所有其他事件所抢占。
答案 1 :(得分：0)
QApplication::compressEvent会丢弃QEvent::UpdateRequest，如果已经有一个未经处理的话。因此，如果事件被丢弃，即使重绘也可以立即返回而不进行绘画。您可以通过覆盖updateRequest来检查您的compressEvent事件是否被丢弃。