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

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

0

Сообщение от kapbepucm А Вы уверены что правильно считаете время отрисовки кадра?

Уверен. Совершенно не важно в каком месте renderNow считать время (если это место всегда одно и то же). Т. к. renderNow работает циклически. Это в любом случае будет период цикла. Не учли текущую swapBuffers - зато учли предыдущую. Можете сами проверить.

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

А можно ли как-то задать приоритеты для событий?

0

Я скомпилировал приложенный вариант, у меня вообще нет реакции на мышь. Серый круг ходит слева направо и обратно.
На кнопки "Стрелка вверх/вниз/влевов/право" реагирует изменением размера.
Также в левом верхем углу есть строки
render: 16ms
frame: 16ms
Если не нажимать клавиши, то render: 0ms.

Вложения

events1.zip (5.9 Кб, 3 просмотров)

0

Задержка есть, причину ещё не искал.

0

Сообщение от peter_irich у меня вообще нет реакции на мышь

Пример про клавиатуру, я же написал.

0

Сообщение от Geek Geekson А крутой и современный Qt еле ворочает ластами.

Тут нужно в корень смотреть. А это много часов.
Про всю иерархию и систему сообщений Qt. Начиная с QCoreApplication.
Как костыль, куда его правильно вставить в такой, довольно плохой архитектуре событий как в твоем примере, я хз:

0

SmallEvil, processEvents() уже пробовал. Вызывает непонятные краши. Кроме того, не рекомендуется самими авторами Кьюти.

И "корень" тут я хз где, потому что, как уже писал, даже прямой асинхронный вызов клавиши из WinAPI (т. е. в обход всего механизма Кьюти) никак на задержку не влиял.

А чем тебе плоха "архитектура событий" в моём почти тривиальном примере? Предложи тогда хорошую

0

Сообщение от Geek Geekson processEvents() уже пробовал. Вызывает непонятные краши. Кроме того, не рекомендуется самими авторами Кьюти.

Почему у меня не крешится?
Хотя да, такое ощущение что может быть рекурсия.
Хоть я её и не вижу.

Сообщение от Geek Geekson И "корень" тут я хз где, потому что, как уже писал, даже прямой асинхронный вызов клавиши из WinAPI (т. е. в обход всего механизма Кьюти) никак на задержку не влиял.

Нужен переводчик.

Сообщение от Geek Geekson А чем тебе плоха "архитектура событий" в моём почти тривиальном примере?

Таймер забивающий всё и вся.

Сообщение от Geek Geekson Предложи тогда хорошую

Что именно должно происходить?
Для твоего случая у Qt припасено спец. случай для таймера.

0

Сообщение от SmallEvil Нужен переводчик

Нажатия клавиш получал не в keyPressEvent, а вызывая GetAsyncKeyState из WinAPI, прямо перед отрисовкой. Выше всё писал же.

Сообщение от SmallEvil Таймер забивающий всё и вся

Насколько знаю, сигналы эти нигде не копятся. Вот из доков:

All timer types may time out later than expected if the system is busy or unable to provide the requested accuracy. In such a case of timeout overrun, Qt will emit timeout() only once, even if multiple timeouts have expired, and then will resume the original interval.

Т. е. если был очередной сигнал таймаута (или несколько) - слот, присоединённый к нему, будет вызван снова один раз (как только поток до него дойдёт). Всё. И вообще такой способ анимации по таймеру - везде и рекомендуется. Вон в примерах глянь (collidingmice например).

Сообщение от SmallEvil apptimer -> start(0);

Попробовал - всё так же.

Добавлено через 2 часа 30 минут
Интересно. Поставил таймеру период большой, например apptimer -> start(250) - тогда действительно та задержка пропадает. И реакция идёт через 1 кадр. И только если сильно увеличивать нагрузку (так что её рисование занимает дольше 250 мс) - тогда 4-кадровая задержка появляется. Значит действительно таймер забивает события клавиатуры (хотя по докам не должен).

Тогда по идее надо сделать этот таймер single shot, и в конце renderNow запускать его снова (с ненулевым периодом).

Попробовал - и нифига, всё та же задержка. Хотя по идее уже ничто не забивает события. И как быть тогда? Как тогда обеспечить цикличность renderNow с высокой частотой (ограниченной только скоростью рендеринга), но чтобы между её вызовами обрабатывались все события?

0

0

Я запустил ещё раз - задержка происходит после использования клавиш "Вверх/Вниз". когда движется тёмно-зелёный прямоугольник.
При запущенном "Systrem monitor" видно, что его перерисовка загружает процессор.
Светло-серый круг совершенно не загружает, ни при движении, ни при изменении размера.

Вложения

events2.zip (11.7 Кб, 3 просмотров)

0

peter_irich, не надо тут это писать. Лучше что-нибудь полезное напиши.

0

Сообщение от Geek Geekson что-нибудь полезное напиши

Давай попробуем один exe на разных системах.
Я не вижу у себя задержки, по крайней мере по своим критериям.
Может эксперт увидит.

Вложения

deploy.zip (11.24 Мб, 6 просмотров)

0

SmallEvil, та же задержка.

Добавлено через 1 час 44 минуты
SmallEvil, у тебя значение "frame" сколько мс показывало когда ты проверял?

У себя тестил на 2 разных машинах (и свои тоже) - на обеих та же задержка.

0

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

Это с start(0). Та самая сборка.
Но какая разница? На таймерах толкового игрового цикла не получишь.

Миниатюры

 

0

SmallEvil, я уже сделал и совсем без таймера, вызывая requestUpdate() в конце отрисовки, и перехватывая QEvent::UpdateRequest - как в доках написано. Всё ровно так же, хоть тресни. Clean в проекте делал.

Добавлено через 5 минут
SmallEvil, у тебя на скрине frame показывает 1744 мс. И хочешь сказать что реакция программы на нажатие у тебя также следует примерно через 1,7 с? У меня при таких условиях - только через 7 - 8 с.

0

Сообщение от Geek Geekson с ускорением OpenGL

Ну как минимум это дает задержку. Если двойная буферизация, то в 1 кадр, если тройная, то в 2 кадра. Конечно можно использовать всего 1 буфер, но тогда будут артефакты при рисовании.
Еще не известно как под капотом Qt все это рисует, там может не в 1 проход, а так же с промежуточными буферами/текстурами.

0

И ещё с этими таймерами, зависит от аппаратной составляющей, драйверов и ОС.
Как видим, один и тот же код ведет себя немного по разному на разных машинах/ОС.

И ещё одно, на счет такого ввода.
Какой практический смысл?

Ведь естественно что когда происходит долгий рендеринг то нет никакой гарантии получения других сообщений.
То что QT где то там хранит небольшую очередь ввода от мыши/клавиатуры, это, ну такое себе.

0

SmallEvil, ответь пожалуйста:

Сообщение от Geek Geekson у тебя на скрине frame показывает 1744 мс. При этом, через сколько у тебя следует реакция программы на нажатие? Также примерно через 1,7 с или дольше? У меня при таких условиях - только через 7 - 8 с.

0

Сообщение от Geek Geekson ответь пожалуйста

Да.
Там где много похожих значений, там было нажато быстро много ESC.
Могу видео сделать.
Код был модифицирован не критично.
Старт таймера с аргументом 0. И я убрал метод kepressed, так как ты уже event переопределил.
Просто было пару экспериментов.

Добавлено через 2 минуты
Windows 10 x64, двухлетний бюджетный ноут с SSD, со встроенной видяхой.
Отключены фаерволы дефендоры ОС(чистое зло).

Добавлено через 1 минуту

Сообщение от SmallEvil И я убрал метод kepressed

Обработка событий клавиатуры был перенесен в event.
Но это, опять же, некритично.

0

Прикрепил исходники, толку от них будет ноль, мы уже всё выяснили бинарниками.

Вложения

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

0