Comments 9
>a.installEventFilter(&w);
Ставить EventFilter на QApplication — это очень и очень плохая идея, имеющая большой оверхед — все события от приложения будут им анализироваться и там далеко не только PaintEvent'ы будут, нельзя так делать.
Таймер с 0вым интервалом это тоже ещё те грабли, вообще в коде сплошные грабли — он совершенно не переносим, нет никакой гарантии, что эта же схема заработает в макоси или линуксе. Раз в документации не гарантируют, что такое будет работать, то лучше это не использовать.
Я бы посоветовал покурить в сторону компрессии событий а также лучше уж перегрузить QApplication а не заниматься навешиванием фильтров
Ставить EventFilter на QApplication — это очень и очень плохая идея, имеющая большой оверхед — все события от приложения будут им анализироваться и там далеко не только PaintEvent'ы будут, нельзя так делать.
Таймер с 0вым интервалом это тоже ещё те грабли, вообще в коде сплошные грабли — он совершенно не переносим, нет никакой гарантии, что эта же схема заработает в макоси или линуксе. Раз в документации не гарантируют, что такое будет работать, то лучше это не использовать.
Я бы посоветовал покурить в сторону компрессии событий а также лучше уж перегрузить QApplication а не заниматься навешиванием фильтров
на самом деле можно было обойтись и без eventFilter, через перегрузку closeEvent у виджета к примеру. Но только я не понимаю чем перегрузка QApplication лучше, все равно ведь придется перегружать event()? Ну а про оверхед ничего не могу сказать, по идее просто перед передачей событий в дерево объектов вызывается eventFilter для моего qapplication, а в коде eventFilter всего одна проверка.
Проверка то одна, но она затрагивает все события в QApplication, поэтому будет вызываться очень часто, плюс если мне память не изменяет, могут возникать проблемы со сжатием событий.
Не обязательно же event() можно и paintEvent перегрузить. Но имхо в любом случае код с перегруженным QApplication'ом будет лучше смотреться, чем странные выкрутасы в main.cpp
Не обязательно же event() можно и paintEvent перегрузить. Но имхо в любом случае код с перегруженным QApplication'ом будет лучше смотреться, чем странные выкрутасы в main.cpp
ок, я уже написал, что можно было и без eventFilter обойтись. Ну а кроме этого выкрутасов нет?!
На самом деле в играх rendering — «перерисовка» далеко не всегда происходит на idle, большинство движков вообще-то не event driven, a устроены скорее как некий конвеер на котором обработка событий только один из этапов. Я использую Qt в своем движке и при этом не запускаю Qtшный exec() a вызываю processEvents() перед отрисовкой, такой подход сильно упрощает flow игры.
да ладно? во всех исходниках в том числе DirectX сэмплах перерисовка происходила постоянно в отсутствие сообщений к оконной системе.
Почти то же самое, или я ошибаюсь?
Я использую Qt в своем движке и при этом не запускаю Qtшный exec() a вызываю processEvents() перед отрисовкой, такой подход сильно упрощает flow игры.
Почти то же самое, или я ошибаюсь?
Sign up to leave a comment.
Idle Event в Qt