Поскольку я никогда не слышал о GLXWindow , мне стало интересно, что это. В большинстве обсуждений не разъясняется , почему это необходимо, и распространяются только предположения, включая мой ответ.
Первое, что нужно уточнить, это то, что было введено GLXWindow в GLX 1,3 . Более старые версии, включая GLX 1.2 , определяют следующий список GLXDrawable : { Window , GLXPixmap }, с GLXPixmap создан за пределами экрана X Pixmap . В спецификациях не разъясняется, почему GLXPixmap необходим поверх X Pixmap, в то время как X Window можно использовать напрямую, но есть предположение, что в определении X Pixmap чего-то не хватает, что GLX необходимо сохранить в GLXPixmap ...
GLX 1.3 расширено определение GLXDrawable как { GLXWindow , GLXPixmap , GLXPbuffer , Window }. Так что вы можете увидеть новый элемент GLXPbuffer , который был попыткой улучшить отрисовку за пределами экрана до того, как объекты Frame Buffer Objects (FBO) были представлены в самом OpenGL. В отличие от растровых изображений и windows, GLXPbuffer создается с нуля и не имеет отношения к X. Существует также новое GLXWindow с примечанием:
Для обратной совместимости с GLX версий 1.2 и более ранних, контекст рендеринга также может использоваться для рендеринга в Window.
Так что GLXWindow больше похоже на попытку унифицировать API ( и внутренние логики c) во всех GLXDrawable , а не инструмент, который что-то исправляет, так как он не расширяет возможности X Window с первого взгляда.
Делает GLXWindow представить что-то новое? На самом деле, это так! GLX 1.3 также представила новую функцию glXSelectEvent () , которая позволяет обрабатывать специфичные для GLX c события в потоке X11. Так что функция работает с GLXWindow и GLXPbuffer, но не с X Window (так как она была специально создана, чтобы отличать события guish GLX от обычных). Смущает, что единственное событие c со спецификацией GLX, определенное спецификациями, относится к типу GLXPbufferClobberEvent , которое кажется более подходящим для устаревших PBuffers и вспомогательных буферов Window (в настоящее время в базовых спецификациях OpenGL их заменяют FBO).
Поэтому лично я не вижу никакой практической причины для создания GLXWindow вместо использования самого X Window вместо того, чтобы просто следовать рекомендациям спецификаций GLX (заявив, что использование X Window предназначено только для совместимости с приложениями, написанными для более старых версий GLX) и использующими «очищенный» API.
Относительно glXCreateNewContext () против glXCreateContext () , это связано с введением GLXFBConfig , поскольку определение X Visual было сочтено недостаточным для представления всех необходимых деталей. Из спецификации:
Вызов glXCreateContext (dpy, visual, list share, direct) эквивалентен вызову glXCreateNewContext (dpy, config, тип рендеринга, list share, direct), где config - это GLXFBConfig, определяемый GLX_FBCONFIG_ID атрибут visual.
Относительно glXMakeCurrent () vs glXMakeContextCurrent () , последний, представленный в более новых версиях GLX, позволяет использовать различные доступные для чтения и чтения буферы так же, как это позволяют современные FBO, что также ясно из спецификации:
Вызов glXMakeCurrent (dpy, draw, ctx) эквивалентен вызову glXMakeContextCurrent (dpy, draw, draw, ctx). Обратите внимание, что ничья будет использоваться как для рисования, так и для чтения.
Что касается современного использования OpenGL 3+, GLX здесь не проблема - просто используйте расширения GLX, такие как GLX_ARB_create_context_profile для создания контекста (текущая реализация библиотеки Mesa предоставляет более высокие версии OpenGL при создании Core Profile , но в случае проприетарных драйверов таких различий обычно нет) некоторые опции отсутствуют по сравнению с GLX) или Wayland / Mir, если вы фанати c к новым серверам отображения и хотите избавиться от X от зависимостей (Wayland реализует слой совместимости с Xlib, так что он не является ограничителем показа для в настоящее время).