Qt с задержкой реагирует на клавиатуру и мышь

В простом проекте без нагрузки сделал QWindow, рядом с позицией курсора (QCursor::pos()) рисуется фигура. Её реакция отстаёт от курсора на целых 3 кадра. А реакция на keyPressEvent вообще 5 кадров. Причём рисование окна идёт с ускорением OpenGL. Отключение vsync задержку не убирало, только делало короче по времени (из-за того что сам кадр стал короче), но если мерить в кадрах - она даже длиннее становилась - 5 кадров вместо 3. Можно ли средствами Qt убрать эту тормознутость, или спасение только в winapi?

0

Сам я давно проектов на Qt не пишу, но думаю, что тут спросят, что Вы делаете в paintEvent() и в keyPressEvent().
И как рисуется фигура - вручную или специализированной функцией.

0

peter_irich, это не виджет, а наследник QWindow, у него нет paintEvent(). Кадр рисуется в собственном методе, по срабатыванию QTimer. В методе всё по примерам - просто создаётся QPainter, делается fillRect() и затем drawPolygon(). Таймер можно поставить хоть на 1-2 мс (будет 500 или 1000 фпс). Задержка всё равно огромная, в несколько кадров. Можно конечно и на виджете попробовать (QOpenGLWidget) но думаю будет всё так же. Я его тестировал раньше, QWindow больше понравился, и можно не тащить модуль Widgets в проект. В доках где-то видел ещё что QWindow потенциально более быстрый.

В keyPressEvent() ничего особенного не делается, только обновляется нужная переменная.

0

Т.е. в "методе" делается то, что, я думал, делается в paintEvent(). А где обрабатываются сообщения от мыши? Должен быть mousePressEvent().
Я пока ничего предположить не могу, м.б., Вы приложите весь проект? Тут есть знающие люди, если не я, то он и ответят.

0

Сообщение от peter_irich А где обрабатываются сообщения от мыши?

QCursor::pos(). Пока только позиция. Пример бы сделал, времени пока мало.

0

Сообщение от Geek Geekson Пример бы сделал, времени пока мало.

да, минимальный пример, демонстрирующий проблему, скорее всего помог бы найти причину

0

kapbepucm, да в принципе можно открыть какой-нить из кьютишных примеров про QPainter, и сделать чтобы над курсором рисовалась всегда фигура. И просто подвигать курсор по экрану и глянуть, насколько отстаёт фигура от него. Я ещё снимал экран скоростной съёмкой и резко двигал курсор - там эти кадры отставания видно чётко.

0

Сообщение от Geek Geekson peter_irich, это не виджет, а наследник QWindow, у него нет paintEvent(). Кадр рисуется в собственном методе, по срабатыванию QTimer.

Geek Geekson, полагаю проблема не в отрисовке, а в таймере. У меня возникла подобная проблема при попытке отрисовать бегущую цепную линию для вырезанных элементов (как в excel) посредством отрисовки по срабатываниям таймера. Как выяснилось виджет перехватывает очень много других таймеров, помимо заданного мною. Из-за чего приложение полностью грузило одно ядро. Решение проблемы пока не нашел, поэтому Вам посоветую попробовать переписать отрисовку минуя реализацию через события таймера.

0

Ilot, нет, с загрузкой проца проблем нет. Даже таймер на 1 мс совсем не грузит ядро (загрузка в диспетчере 0-1 %). Я просто приконнектил сигнал timeout к функции отрисовки. У вас по-другому сделано, через событие. И как там правильно сказали, по идее в обработчике надо вызвать аналогичный родительский метод. В доках про это есть.

1

Вот пример с клавишами. Стрелками изменять размер и кол-во кружков, чтобы создать нагрузку.
Нажатие Esc - выводит момент в мс со старта программы: 1-е число - значение из timestamp события, второе - значение времени, полученное в обработчике. Видно что второе запаздывает на один кадр.

Может быть маленькое расхождение из-за того что стартовый момент времени (сохранённый в конструкторе) мог быть не совсем тот что использует внутри себя механизм событий. Но явно видно что отставание обработчика от штампа всегда 1 кадр. Это ещё можно понять, но это ещё цветочки. А реальная реакция на нажатие у меня например отстаёт на 4 или 5 кадров. Т. е. можно например добавить нагрузку стрелками, чтобы кадр рисовался скажем 400 мс, и нажать Esc - программа реагирует не через эти ожидаемые 400 мс, а где-то через 2 с. Т. е. целые 4 кадра событие где-то гуляет, и только потом регается в очереди. Что за странная задержка? Кьюти какой-то жуткий тормоз в этом плане.

На малых нагрузках это отставание в 4 кадра тоже есть.

Вложения

events.zip (2.5 Кб, 33 просмотров)

0

Попробовал вместо ивентов делать через winapi (GetAsyncKeyState), прямо в функции отрисовки, непосредственно перед рисованием. В целом всё так же! И та же задержка в 4 кадра.

Как будто сами кадры перед выводом становятся в какую-то очередь и рисуются не сразу. При том что у меня игровой моник с нулевым input lag. Ещё в настройках видеокарты пробовал включать режим низкой задержки - не влияло. Может хоть кто-то прольёт свет на это всё. Как сделать по настоящему отзывчивое управление.

0

Там keyPressEvent() можно улучшить: вместо многих if,из которых выполнеяется только одим использовать switch().
При использовании таймеров попробовать таймер реального времени.

0

Сообщение от peter_irich При использовании таймеров попробовать таймер реального времени

Это который Qt::PreciseTimer? Так и было изначально. Да и не даёт это ничего. А switch тем более.
Кто-нибудь тестил пример? Такая же задержка?

0

Geek Geekson, может попробуешь всё тоже в UnrealEngine или в другом игровом движке?
Я уже просто ссусь кипятком так интересно, что же здесь решается)

0

SmallEvil, а пример пробовал? Есть задержка в 4 кадра? А то я тоже начну кипятком ссаться

0

Я запустил пример, вижу двигающийся круг. Нажимаю клавишу [esc]- появляются 2 цифры но отличаются не на 4 кадра, а на порядок, например 15464078 и 2062. Пока не понимаю, что у меня тут от чего отстаёт. Смотрю код, но понимание почемуто не приходит.
Вижу обработчик клавиатурных событий- он однозначно не вызывается в тот самый миг, когда клавиша нажата (там всё вызывается в порядке определённой очереди).

0

Сообщение от kapbepucm появляются 2 цифры но отличаются не на 4 кадра, а на порядок, например 15464078 и 2062

1-я цифра - ровно то что возвращает timestamp() полученного события. Вторая - момент в мс со старта, рассчитанный в самой проге. И почему этот timestamp() у вас такой большой - это странно, но все вопросы к Qt а не ко мне. Но на эти цифры можно пока не смотреть.

Сообщение от kapbepucm обработчик клавиатурных событий- он однозначно не вызывается в тот самый миг, когда клавиша нажата (там всё вызывается в порядке определённой очереди)

Ну это понятно. Вопрос не в этом.

Самое главное - понажимайте стрелки вверх и вправо, чтобы увеличить кол-во и размер кругов (создать нагрузку), чтобы "frame:" показывало где-нибудь 300 - 500 ms.
И потом нажмите Esc и примерно прикиньте через сколько времени появилась реакция (сменился фон).
У меня это время раз в 5 больше фрейма, то есть когда "frame: 400 ms" - фон меняется где-то через 2 секунды только. Хотя должен, по идее, максимум за 800 мс (т. е. 2 кадра).
Можно ещё больше нагрузку дать, чтобы задержка была лучше заметна.

0

Сообщение от Geek Geekson У меня это время раз в 5 больше фрейма, то есть когда "frame: 400 ms" - фон меняется где-то через 2 секунды только. Хотя должен, по идее, максимум за 800 мс (т. е. 2 кадра).

вот такое наглядно не вижу (хотя не берусь утверждать, что его нет)
Что я вижу в работающей программе (я потыкал много вверх и вправо и Escape):
-куча операций выполняется в renderNow
-в то же время накапливаются сигналы от таймера, что пора запускать renderNow повторно
-также ждут своего часа клавиатурный обработчик
-когда наконец renderNow выполнился, планировщик очереди запускает именно renderNow, а клавиатура ждёт в более низком приорите, так как у нас Qt::PreciseTimer и ещё сигналов таймера поступает огромное количество (обрабатывается только последний, остальные дропаются)
-обработка Esc происходит с значительным опозданием
Ну вроде всё логично...
Осознание того, как мы тут замеряем реальный миг нажатия клавиатуры, который необходимо сопоставить с нужным номером кадра, ко мне всё ещё не пришло У нас же тут не разные потоки а один- или рисуем или смотрим что там от клавиатуры прилетело.

0

Сообщение от kapbepucm Осознание того, как мы тут замеряем реальный миг нажатия клавиатуры, ко мне всё ещё не пришло

А прямо физически - для того я нагрузку и увеличиваю, когда задержка уже составляет секунды. Чтобы её было видно. То есть жмём клавишу и смотрим через сколько будет реакция. А "frame" показывает сколько мс заняла вся отрисовка текущего кадра. Элементарно же. А реакция по идее должна следовать максимум через 2 кадра, т. е., как я представляю - во время рисования какого-то кадра была нажата клавиша. Кадр кончился - запускается очередная итерация механизма событий - событие приходит в очередь (хотя почему бы прямо тут не выполниться обработчику, если очередь пустая). Ну ладно, рисуется следующий кадр. Потом событие извлекается из очереди и вызывается обработчик. То есть макс. задержка по идее должна быть 2 кадра. А никак не 5.

И например в древнем (и ныне покойном) Blitz Plus (на котором я писал когда-то) именно так. Вот прямо ща проверил, на этой же машине - реакция максимум 2 кадра, независимо от длины кадра. А крутой и современный Qt еле ворочает ластами.

И задержка походу не в самом механизме событий. Т. к. пробовал и через WinAPI (см. выше). ХЗ откуда она берётся.

0

Сообщение от Geek Geekson А "frame" показывает сколько мс заняла вся отрисовка текущего кадра.

А Вы уверены что правильно считаете время отрисовки кадра? По коду вижу, что замер просходит внутри renderNow, однако не учитывается два вызоваЯ точно не скажу, как там с OpenGL, но обычная Qt-шная рисовалка окон как раз основную работу и делает в QPainter.end или при корректной деструкции QPainter.
И также не учитывается то, что порядок обработки событий в Qt не идёт строго по их поступлению, чтото может, взависимости от приоритетов, выполнится раньше или пожже. Ну то есть мы жмём на клавишу Esc, Qt это видит и знает, но в какойто момент вперёд пускает обработчика таймера, а не обработчика клавиатуры.

0