Точная задержка при отрисовке экрана и событиях нажатия клавиш в Qt
Я работаю над проектом Qt, в котором точное время, когда происходят определенные события, имеет первостепенное значение. Чтобы быть конкретным: у меня есть очень простая анимация, которая должна быть выведена на экран в определенное время, скажем, t1. Как только я выпускаю QWidget Обновление, чтобы запустить анимацию, для отображения обновления на экране потребуется небольшое время (в зависимости от частоты обновления экрана и т. д.). Мне нужно измерить это дополнительное время DT. Я не уверен, как это сделать.
Я думал об использовании QTime а также QElapsedTimer объект в событии краски QWidget но я не уверен, что это достигнет моей цели.
Аналогично, когда пользователь нажимает клавишу, она будет зарегистрирована после небольшой задержки, основанной на частоте опроса клавиатуры. Мне нужно учитывать и эту задержку. Если бы я мог получить скорость опроса, я в среднем знаю, сколько будет задержка.
Решение
То, что вы просите — по определению — невозможно изнутри компьютера.
Как вы ожидаете, что сможете определить, когда пиксель «появился» на экране, без датчика, прикрепленного к монитору и синхронизированного с атомными часами, к которым компьютер имеет доступ? 🙂
Шансы еще больше сопоставлены с Qt, потому что он обычно используется в качестве уровня абстракции поверх Win / OSX / Linux. Те не были Операционные системы реального времени любого рода в первую очередь.
Все, что вы можете знать, это когда вы просили что-то случиться. Затем вы можете определить, сколько времени потребуется, чтобы вернуть контроль и сделать еще один запрос. Делая это, вы можете установить некоторые ожидания относительно базовой пропускной способности «частоты кадров», но существует множество факторов, которые могут привести к значительным колебаниям производительности в любой момент времени.
Если вы можете перейти к уровню ядра / драйвера, вы сможете найти более точную меру того, когда фактический эффект пошел на аппаратное обеспечение. Но это не сфера Qt, и все равно не говорит вам «фактический» ответ, когда эффект проявился во внешнем мире.
Самое лучшее, что вы собираетесь получить из Qt — это периодический QTimer. Он может сделать обратный вызов с разрешением (примерно) миллисекунды. Если этого недостаточно, вам понадобится лодка поменьше. 🙂
Вы можете получить небольшую поддержку от вещей, связанных с поисковым термином «таймер высокого разрешения»:
Другие решения
Я думал об использовании
QTimeа такжеQElapsedTimerобъект в событии краскиQWidgetно я не уверен, что это достигнет моей цели.
Это, по сути, единственный способ сделать это, и это все, что вы можете сделать на самом деле. Больше ничего нельзя сделать без использования операционной системы реального времени, пользовательских драйверов или внешнего оборудования.
Вам может не понадобиться оба — QElapsedTimer измерения времени, прошедшего с момента последнего обновления, достаточно.
Обратите внимание, что когда цикл событий пуст, задержка между вызовами widget.update() и paintEvent выполнение занимает менее микросекунды, при условии, что ваш процесс не был прерван.
это эксперимент с реакцией времени для некоторых исследований. Представлен визуальный ввод, на который пользователь реагирует с помощью клавиатуры или мыши. Чтобы точно определить время реакции, мне нужно знать, когда стимул был представлен на экране, а когда была нажата клавиша.
По сути, существует только один способ сделать это правильно, не прибегая к операционной системе реального времени или специальному драйверу, и множество способов сделать это неправильно. Итак, каков правильный путь?
Небольшая область экрана должна изменить цвет или яркость одновременно с представлением визуального стимула. Вы прикрепляете оптоволоконный кабель к экрану и подаете его в приемник, подключенный к таймер внешнего события. Замыкание контактов в клавиатуре также подается на тот же таймер событий. Это позволяет точно рассчитать время ожидания ответа, не обращая внимания на задержки операционной системы, прерывание потока и т. Д. Таймер событий может быть чем-то дешевым, как Arduino, если вы готовы сделать немного больше работы по разработке.
Если вы демонстрируете стимул повторно и нуждаетесь в определенном времени между презентациями стимула, вы просто часто повторяете презентацию и собираете в своих данных как задержку ответа, так и синхронизацию стимула к стимулу. Затем вы можете отказаться от презентаций, которые выходили за пределы желаемых допусков.
Этот подход не зависит от экрана, и вы можете использовать его даже на мобильном устройстве, если он каким-то образом взаимодействует с аппаратным обеспечением вашего таймера. Конечно, аппаратное обеспечение таймера может быть подключено к сети, что облегчает взаимодействие.