Обмен буферов и очистка назад с использованием оконной системы (GLX)
При переключении между задним и передним буферами содержимое в заднем буфере становится неопределенным. Я хотел бы определить это с помощью «оконной системы», такой как GLX, EGL, WGL. Использование «родного» рендерера, такого как OpenGL (glClear) — мой план резервного копирования, не беспокойтесь о нем. Причина в том, что это резервная копия, потому что я не хочу связываться с нативными контекстами рендеринга. В этом вопросе я остановлюсь на X / GLX, но если вы склонны описывать, как это сделать в других средах, продолжайте.
Из документации Xlib (http://www.x.org/docs/X11/xlib.pdfЯ нахожу операцию, XClearWindow, для очистки окна с «фоновым пикселем» (кстати, удивительное имя … нет).
- XClearWindow очищает передний / задний или оба буфера? Я думаю, что обратный буфер имеет смысл, но я не могу понять это только из документов Xlib … И если кто-то спрашивал о тройных буферах, это был не я!
- Это синхронно с рендерингом OpenGL, или я должен синхронизировать себя, например, вызывая glxWaitGL перед операцией?
- Команда блокируется, т.е. останавливается до завершения? Реализация зависит?
Другие предложения о том, как очистить задний буфер после перестановки с использованием оконной системы (GLX), приветствуются.
Ура!
Решение
При переключении между задним и передним буферами содержимое в заднем буфере становится неопределенным.
Да, и это хорошо.
Я хотел бы определить это с помощью «оконной системы», такой как GLX, EGL, WGL
Зачем? Кроме того, это так же неопределенно, как фон после свопа, из которого ничего хорошего не получится.
В лучшем случае это просто ухудшит производительность, если OpenGL DDX знает о XClearWindow, которое он будет синхронизировать. В худшем случае вы вводите условия гонки, между которыми результаты непредсказуемы.
Другие предложения о том, как очистить задний буфер после перестановки с использованием оконной системы (GLX), приветствуются.
Используйте правильную операцию OpenGL: glClear(…),
Другие решения
После некоторых исследований я, возможно, нашел решение. Документы, кажется, в порядке, но у меня не было возможности проверить это на практике. Я обновлю ответ кодом, как только получу что-нибудь работающее.
XClearWindow очищает передний / задний или оба буфера?
Х не имеет понятия двойных буферов. Всякий раз, когда взаимодействует с X против окна с двойным буфером, затрагиваются оба буфера. Исключение составляют операции чтения, такие как XGetImage которые работают только на передний буфер.
X расширяется с помощью концепции двойного буфера через X Double Buffer Extension или xdbe: http://www.x.org/releases/X11R7.6/doc/xextproto/dbe.html#dbeswapbuffers
xdbe предоставить XdbeSwapBuffers операция похожа на glxSwapBuffers предоставлено GLX. Есть несколько важных отличий:
- XdbeSwapBuffers не управляет синхронизацией с любым клиентом
API, как у glxSwapBuffers. Пользователь должен сделать это вручную. К счастью, GLX обеспечивают отличный
операции синхронизации (glxWaitGLа такжеglxWaitX) это не остановится
выполнение. Это в значительной степени отвечает на мой второй вопрос. - glxSwapBuffers выполняет неявный сброс (
glFlush) для текущего
контекст. XdbeSwapBuffers не имеет. Когда смывать или нет
дизайнерское решение. - XdbeSwapBuffers может поменять несколько окон за один вызов.
- XdbeSwapBuffers может иметь другое поведение при замене:
«Не определено», «Фон», «Нетронуто», «Скопировано». Читать ссылку
для деталей.
Для очистки после замены на предопределенный цвет рекомендуется использовать поведение свопинга «Фон». То, что нужно очистить, может быть настроено через X и может быть растровым изображением или одним цветом (фоновый пиксель).
Команда блокируется, т.е. останавливается до завершения? Реализация
зависит?
Приложение, использующее X, должно обеспечивать свои собственные механизмы синхронизации во многих ситуациях. Это указывало бы на асинхронный шаблон выполнения, но сам стандарт не требует этого. Я бы пошел с «определением реализации» с сильным предположением, что большинство команд для большинства платформ выполняются асинхронно.