События обновления QWidget, но без визуального обновления
Использование Qt4.8 на Mint Linux 12 я реализовал простое окно, содержащее QTableView для отображения содержимого модели. Данные модели постоянно обновляются (сообщения журнала) и dataChanged() сигнал испускается на регулярной основе (т. е. каждые 100 мс).
проблема, которую я вижу, - это заикание визуальных обновлений на столе.
я установил фильтр событий в окне, которое считает updateRequest - введите события, которые должны вызвать перекраску виджета (также на дочерних виджетах, т. е. tableView). Они приходят со средним временем ~170ms между ними и стандартным отклонением ~90ms (что довольно велико, я думаю). Однако воспринимаемая скорость визуального обновления составляет всего два или три раза в секунду, и мне интересно, почему. Кажется, что не все updateRequest события вызывают перекраску виджета или то, что оконная система глотает визуальные обновления.
в качестве второго теста я заставил окно обновить себя, вызвав repaint или update каждые 100 мс. Использование repaint, Я видел соответствующее увеличение updateRequest - тип событий и уменьшение стандартного отклонения зазоров; с update, число не увеличилось. Однако в обоих случаях наблюдалось лишь умеренное увеличение предполагаемой скорости обновления.
также: есть ли хороший метод для измерения того, как часто виджет на самом деле перекрашивается без перегрузки его paintEvent обработчик? Может быть, что-то из QTest?
обновление: я продлил свое событие фильтр также поймать paintEvent-тип события. Есть только однозначное число тех, против > 1000 updateRequest-тип события.
2 ответов
вы должны инструмент диспетчера событий aboutToBlock() и awake() сигналы и измеряют время между ними, используя QElapsedTimer. Экземпляр диспетчера событий для текущего потока возвращается статическим QAbstractEventDispatcher::instance().
если цикл событий спит для очень небольшой части вашего окна измерения времени, это означает, что в потоке GUI происходит слишком много вещей. Вы можете подсчитать, как долго цикл событий спал, скажем, в течение последней секунды. Если это ниже 10%, вы можно ожидать медленных обновлений и еще много чего. Помните, что события обновления находятся в очереди с Qt::LowEventPriority. Они будут опережать стандартные сигналы в очереди и почти все другие события.
QApplication::compressEvent выкладывает QEvent::UpdateRequest, если уже есть один необработанный. Таким образом, даже перекраска может немедленно вернуться без покраски, Если событие отброшено. Вы можете проверить, если ваш updateRequest события отбрасываются перезаписью compressEvent.