Очередность событий

[Igors]

Добрый день

Есть несколько окон с OpenGL рисование которых может быть достаточно долгим. Когда юзер что-то изменил  я вызываю update для всех окон нуждающихся в перерисовке, в результате получаю paintEvent. И вот когда юзер- пулеметчик выбирает слишком быстро - получается эффект засорившейся сливной трубы. Напр за секунду он успел что-то изменить 4 раза, за это время еще и первое обновление не успело. Потом рисуется второе нажатие и.т.д. А надо рисовать сразу 4-е, последнее. Как этого добиться?

Спасибо

[Swa]

Первое что приходит на ум - задержка. Рендер запускается через, например, 0,5 - 1 сек с последнего действия юзера.

[Bepec]

Менеджер обновления, самый простейший  как и предложили обновление по таймеру. Ну или заморочиться с очередями.

[__Heaven__]

Я бы использовал очереди и таймер

[Igors]

Не в первый раз наблюдаю этот эффект - какое-то решение предложено (причем автор даже не говорил "хорошее"), и оно тут же одобряется, без всякого осмысления 

А если объект двигать надо, то как, рывками через пол-секунды? А если геометрии мало или карта приличная? Наверное надо "подбирать скорость", интервал (ох и долго тут один про это спрашивал, до сих пор помню "Это все ясно, но какая ..."  - и так N раз ) 

Мужчины, ну как-то все-таки думать надо 

[Bepec]

Если надо то двигайте. А так четко поставлена задача - проредить поток перерисовок от пользователя.
Там хоть 100 хоть 1кк событий перерисовки быть может. А время перерисовки мы не знаем и рассчитать не можем. Следовательно сделать движение объекта "плавным" мы не в силах.

И вообще - мы говорим о перерисовке. Пользун что то поменял - нужно перерисовывать всё, в том числе и этот ваш движущийся объект, ибо он "старый".

PS конкретизируйте тогда свои требования, у вас с этим проблема если честно. Если вам нужна плавная картинка с постоянно меняющимися параметрами и полным интерактивом, мб стоит тогда подумать о наращивании мощности железа, а не ловле блох с невнятными требованиями?

[Swa]

Не в первый раз наблюдаю этот эффект - какое-то решение предложено (причем автор даже не говорил "хорошее"), и оно тут же одобряется, без всякого осмысления  

А если объект двигать надо, то как, рывками через пол-секунды? А если геометрии мало или карта приличная? Наверное надо "подбирать скорость", интервал (ох и долго тут один про это спрашивал, до сих пор помню "Это все ясно, но какая ..."  - и так N раз )  

Мужчины, ну как-то все-таки думать надо  

Вы не описали подробно условия задачи, а говорите что решение вам не подходит.
В первом посте было: "И вот когда юзер- пулеметчик выбирает слишком быстро" - из этого я сделал вывод, что пользователь набирает текст. Для этой ситуации, ИМХО, таймер подходит.
Если у вас не только набор текста, опишите подробнее, как устроен софт и чего нужно добиться.

[Igors]

Если у вас не только набор текста, опишите подробнее, как устроен софт и чего нужно добиться.

Случаев много, один из них: объекты отображаются в неск окнах, есть еще окно со списком объектов. Юзер может выбирать из списка кликнув на айтем мышей, выбранный объект должен подсветиться во всех окнах - вот собственно и все.

Кстати - а ведь еще давным-давно читал что меседж WM_PAINT "имеет низший приоритет", чего же оно приходит раньше события нажатия? Может это только на Вындоуз? Ой вряд ли. Вообще в Qt 5 не знаю как посмотреть события, он как-то складывает их сначала себе а потом диспатчит из своей очереди. Это может совсем не соответствовать "событиям-первоисточникам" что послал ОС 

[__Heaven__]

ИМХО, какая разница, что там - текст, не текст. Каждые 1/60 секунды вызывать таймер, который будет проверять наличие необходимости в перерисовке. Это приведёт к уменьшению рывков, возможно к ликвидации.

[Igors]

ИМХО, какая разница, что там - текст, не текст. Каждые 1/60 секунды вызывать таймер, который будет проверять наличие необходимости в перерисовке. Это приведёт к уменьшению рывков, возможно к ликвидации.

Вы не можете вызывать таймер, а только получать события от него, причем они придут только если нет никаких др событий. Поэтому в примере выше таймер получите когда выполнены все 4 перерисовки

[__Heaven__]

Таймер вызывает 1 перерисовку. Даже если вы внесли 4 изменения, то они входят в эту 1 перерисовку. Поэтому он "глушиться" большим количеством перерисовок не может. Действия пользователя обрабатываются за кадром.

[Bepec]

Тут прикол в том, что перерисовка может занимать не 20 мс, а неизвестное количество времени

[__Heaven__]

В упор не понимаю.
Ну пусть отрисовывается 10 секунд. Я натыкал 200 раз по окну, после перерисовки они вступают в силу на уровне мозгов. Пришло время следующей перерисовки по таймеру и эти 200 изменений появляются на экране.
Я что-то не так понимаю?

[Igors]

В упор не понимаю.
Ну пусть отрисовывается 10 секунд. Я натыкал 200 раз по окну, после перерисовки они вступают в силу на уровне мозгов. Пришло время следующей перерисовки по таймеру и эти 200 изменений появляются на экране.
Я что-то не так понимаю?

Кто (или куда) должен прийти? Сейчас схема такая (значимые события)

QEvent::MouseButtonPress  (1) // юзер выбрал айтем, делаем update всем окнам 
QEvent::Paint   (1)  // рисуем окно 1
QEvent::Paint   (2)  // рисуем окно 2
...
QEvent::Paint   (last)  // рисуем последнее окно
QEvent::MouseButtonPress  (2)  // юзер опять выбрал айтем, все по новой

Беда в том что когда отработывает первый Paint шустрый юзер уже успел понатыкать раза 3-4. Можно отложить update и сделать его по таймеру, но минусы этого решения очевидны. Хотелось бы получить MouseButtonPress  (2) сразу после QEvent::Paint   (1), ведь рисовалось долго и нажатие уже состоялось. Но (хз почему) не получаю

[__Heaven__]

Хотелось бы получить MouseButtonPress  (2) сразу после QEvent::Paint   (1), ведь рисовалось долго и нажатие уже состоялось. Но (хз почему) не получаю

То есть, нажатия пользователя проглатываются перерисовкой? Это, действительно, странно