История изменений
Исправление quiet_readonly, (текущая версия) :
Контекст OpenGL всегда принадлежит некоторому потоку. Можно забрать его в другой поток, через EGL или другой платформо-зависимый API. Поскольку во всех оконных ОС контекст OpenGL привязан ещё и к окну, то разделить обработку событий и рисование начисто вряд ли получится.
Но есть более хитрые способы: например, работу с API ОС и OpenGL вести в одном потоке, а логику программы прогонять в другом. Получается, что поток рендеринга будет просто брать события ОС и кидать их в свою потокобезопасную очередь, а также принимать объекты-команды рисования, такие как «нарисуй mesh», «нарисуй спрайт», «используй такой-то материал (текстуру, цвет, шейдер)».
Если объекты-команды рисования будут на хорошем и удобном для обоих потоков уровне абстракции, то
- поток рендеринга будет только складывать события в очередь и рисовать по командам рисования (возможно, сортируя их по одинаковым материалам для сокращения числа batches)
- поток логики будет только диспатчить события из очереди, диспатчить свои внутренние события типа «выполнить метод через 1 секунду после того как положили в очередь», и отправлять команды потоку рендеринга.
Чем меньше блокировок и чем лучше команды подходят для сортировки для уменьшения числа переключений состояния, тем выше производительность.
Исходная версия quiet_readonly, :
Контекст OpenGL всегда принадлежит некоторому потоку. Можно забрать его в другой поток, через EGL или другой платформо-зависимый API. Поскольку во всех оконных ОС контекст OpenGL привязан ещё и к окну, то разделить обработку событий и рисование начисто вряд ли получится.
Но есть более хитрые способы: например, работу с API ОС и OpenGL вести в одном потоке, а логику программы прогонять в другом. Получается, что поток рендеринга будет просто брать события ОС и кидать их в свою потокобезопасную очередь, а также принимать объекты-команды рисования, такие как «нарисуй mesh», «нарисуй спрайт», «используй такой-то материал (текстуру, цвет, шейдер)».
Если объекты-команды будут на хорошем и удобном для обоих потоков уровне абстракции, то
- поток рендеринга будет только складывать события в очередь и рисовать по командам (возможно, сортируя их по одинаковым материалам для сокращения числа batches)
- поток логики будет только диспатчить события из очереди, диспатчить свои внутренние события типа «выполнить метод через 1 секунду после того как положили в очередь», и отправлять команды потоку рендеринга.
Чем меньше блокировок и чем лучше команды подходят для сортировки для уменьшения числа переключений состояния, тем выше производительность.