Здравствуйте, AlexGin, Вы писали:

AG>Здравствуйте, Mr.Delphist, Вы писали:

MD>>Здравствуйте, 0x00, Вы писали:

0>>>было интуитивно понятно что экземпляр рендера должен быть один

MD>>Очень опасное самоуспокоение
AG>Но справедливое, если применяешь OpenGL!
... OpenGL текущей реализации. А завтра выходит новый SDK/API/etc с откровением от авторов "мы тут подумали и поняли как несправедлив этот мир, бла-бла-бла... встречайте — concurrent rendering!"

MD>>Скажем, завтра портируем для каких-нибудь гугло-очков или телефона с двумя экранами — и вдруг опа, на каждый экран надо свой рендерер. Или пишем какой-никакой юнит-тест, и надо подоткнуть псевдо-рендерер. А у нас везде MyRenderer::getInstance() натыкан. Будет больно.

AG>Работая с OpenGL, убедился что именно такое решение — правильное!
AG>Второй рендерер — не будет корректно работать в другом потоке или процессе!
AG>Мы для этой цели — применяем мьютекс.

Всё верно: сейчас — ограничивайте мьютексом. Возникнет необходимость — откинете мьютекс и сделаете фабрику.

AG>Если тебе нужно два экрана, сначала следует отрендерить один, затем второй. Одновременно рендерить — это неправильно.
Если hardware/firmware поддерживают такое — почему нет? Вспомните, как сильно плевались в авторов игровых движков, когда массово пошли Hyper-Threading CPU и прочие многоядерники/многосокетники: одно ядро изжаривается с нагрузкой 146%, второе курит бамбук. Видяха ценой в половину компа недоумённо позёвывает и говорит "и это все полигоны, что у вас сейчас есть?"

MD>>Код не должен знать, сколько экземпляров объекта. Он должен пользоваться тем экземпляром, что передан снаружи.
AG>Это вопрос дизайна архитектуры продукта.
AG>Или на уровне дизайна, или на уровне реализации — следует запретить одновременное использование двух рендереров OpenGL.

На уровне реализации. Дизайн менять куда проблематичнее.