Добрый день

Возможно "пользовательский интерфейс" - более подходящий раздел, ну ладно.
Определимся с "долго", конкретный пример: рисуется 25K объектов, обновление одного окна занимает примерно 1.6 сек, это уже затрудняет активность юзверя.

Вечный вопрос  "как быстрее" здесь не стоит, размер данных принципиально не ограничен, 25К работает? А 250К? (как в старом анекдоте про бензопилу). Ну и само собой "гуй не должен замерзать".

Вопрос 1: нужно ли для счастья "выносить в поток"? Чем это грозит и каков "выйгрышь"? Часто подразумевается что это, мол, "решение всех проблем".  Ну в данном случае это лишь "разморозка гуя", быстрее точно не будет, устройство ("карточка" как любовно говорят железячные перцы) одно. А головняк с синхронизацией точно имею.

Вопрос 2: а что собсно делать если отрисовка не усспевает? Полагаем что после отрисовки каждого (из 25К) объекта вызывается ф-ция IsInterrupred() (достаточно быстрая), без нее все равно не обойтись. И вот она вернула true. Дальше что?

Спасибо

Насколько понял, Вы говорите о "грамотной архитектуре рисования". Что, конечно, всегда  интересно (с удовольствием приму участие в обчуждении), но здесь речь не об этом. Полагаем что какое-то рисование есть/имеется, насколько оно быстро/оптимально - др вопрос, в любом случае найдется такой объем данных что скорость отрисовки не успеет за активностью юзера. В этой теме хотелось бы поговоритт как отрабатывать такую ситуацию

Ладно, немного отвлечемся от темы, простой пример: юзер, всего-навсего, выбрал объект из списка (selected), нужно нарисовать его bounding box. И.. для примера выше рисуем все 25К объектов Ну конечно на событиях (может он непрерывно выбирает), но возможности что-то "дорисовать" нет, каждая новая отрисовка начинается "с нуля" и будет молотить все. Поэтому я с сомнением отношусь к "прореживанию" и "группировке"

Вернемся к теме
Лично я не вижу др решения кроме как:

- вывести на экран то что успели (swapBuffers) и выйти (вон) из метода рисования. Это можно с успехом делать в главной нитке. Очевидно такое рисование "огрызков" не впечатляет, но лучшего не видно, если ничего не выводить, то все просто "мэртво" при неуспевающей перерисовке.

Это создает новую проблему - окно осталось необновленным, и рано или поздно нужно все-таки нарисовать его полностью.  Сейчас юзается очевидное решение - если не успели - вызвать update(), т.е. послать новый запрос на рисование в очередь событий. Это работает так-сяк (хреновато).

Еще одна проблема - что писать в ф-ции IsInterrupted() ? Здесь 2 ситуации, первая - драг, очевидна: проверить сдвинулась ли мыша или была отпущена. К сожалению, и здесь проблемы (c QCursor::pos, создам тему об этом)

Второй случай - просто "регулярное" обновление, здесь хужее. Рисование в процессе, и тут юзер чего-то нажал (клаву или мышь). Выходить надо, иначе "гуй заморожен". Но нажатие далеко не всегда ведет к обновлению окон, активный юзер получает эффект "конвульсий" UI   Впечатление что "вынос в поток" эту проблему решает (прерывается при следующем update()), как думаете? Но нырять в отдельную нитку - ну очень не хочется, ничего хорошего об этом не пишут.

Насколько верны мои соображения ?

Да, вот раньше бывало "настоятельно рекомендовали" - а сейчас нет 

Например какой нибудь QCad при перемещении 100500 объектов перемещает только общий для всех boundingBox, сами объекты не рисует при перемещении, ну либо ставит в очередь отрисовки ~раз в секунду.
Другие "прореживают" перемещаемые объекты, берут (к примеру) каждый 10-й, ну либо внутри есть хардкод некоего количества легко перемещаемых объектов, вычисляют коэфф. прореживания, согласно этого хардкода.

О "побочных" вещах
А как Вы можете это сделать "не отдельно"? У каждого эл-та своя геометрия (вертексы и фейсы) и для каждого придется установить атрибуты и вызвать команду рисования. Возможно Вы имеете ввиду оптимизацию установки шейдеров (типа рисуем сначала все эл-ты с одним материалом и.т.д). Ну тут кое-что оптимизировано, кое-что нет, есть о чем поговорить, но это отнюдь не просто и ускорения "в разы" не обещает.

Это не одно и то же. "Формирование кадра" не есть "рисование". Формирование никак не связано с OpenGL, сейчас оно производится в главной нитке (с запуском др для того что можно сделать параллельно), и никаких планов это менять к меня нет. А вот замораживать UI ожидая окончания собсно рисования (установка шейдеров и вызовов glDrawElements/Arrays) когда оно уже потеряло актуальность - явно не годится. И опять приходим к тому же: как прерываться?

Что там "лучше выглядит" (N первых или Nth) - вопрос "второго плана". Важнее как прервать регулярное рисование? Пожуем

- вот мы рисуем (ну вернее посылаем OpenGL команды рисования, строго говоря это еще "запрос") объект за объектом. Что проверять (после каждого)? Нажата клава или мышь? Это можно сделать низкоуровневыми ф-циями, не трогая события. А юзер просто в меню полез. Или открыл окно не имеющее к рисованию отношения. Или еще что. И каждый раз перерисовка заново. А связываться с processEvents на 25K - нереально. И шо ? 

вроде уже давно нет