Что такое контекст рендеринга Opengl?
Нигде, ни в одной книге которую я видел, ни в инете нет четкого объяснения что это такое, кроме как того что это некая структура.
Как понимаю в Windows и Linux они отличаются. По логике можно подумать что это что то похожее на структуру дескриптора формата пиксела.
А что там еще может быть. И почему нигде нет этого описания?
Т.е. грубо говоря контекст это структура в которой содержатся состояния всего конвеера Opengl. И структура эта реализована на уровне ОС. Т.е в той же винде хрен знает что там?
koobik
> Т.е в той же винде хрен знает что там?
окно в котором рисуешь, это и есть контекст (вообще, вот все что делал glut (смена double buffer, рисование куда-то, и подобное), судя по вики и есть контекст). могу ошибаться
Mark.A
opengl32.dll там что? Я думал что все таки реализация конвеера. И структура где то там. А драйвер нужен для устройства(тупо интерфейс между железкой и ОС). Хм., в общем предполагаю что весь конвеер крутится в ОС а результат и функции взаимодействия с железкой через драйвер )
Context state is state that belongs to the GL context as a whole, rather than to instances of the different object types described in section 2.5. Context state controls fixed-function stages of the GPU, such as clipping, primitive rasterization, and framebuffer clears, and also specifies bindings of objects to the context specifying which objects are used during command execution.
The Specification describes all visible context state variables and describes how each one can be changed. State variables are grouped somewhat arbitrarily by their function. Although we describe operations that the GL performs on the framebuffer, the framebuffer is not a part of GL state.
There are two types of context state. Server state resides in the GL server; the majority of GL state falls into this category. Client state resides in the GL client. Unless otherwise specified, all state is server state; client state is specifically identified. Each instance of a context includes a complete set of server state; each connection from a client to a server also includes a complete set of client state.
While an implementation of OpenGL may be hardware dependent, the Specification is independent of any specific hardware on which it is implemented. We are concerned with the state of graphics hardware only when it corresponds precisely to GL state.
Рендеринг 3D графики с помощью OpenGL
Введение
Что такое OpenGL?
OpenGL — cпецификация, определяющая платформонезависимый программный интерфейс для написания приложений, использующих двумерную и трёхмерную компьютерную графику. OpenGL не является реализацией, а только описывает те наборы инструкций, которые должны быть реализованы, т.е. является API.
Каждая версия OpenGL имеет свою спецификацию, мы будем работать начиная с версии 3.3 и до версии 4.6, т.к. все нововведения с версии 3.3 затрагивают мало значимые для нас аспекты. Перед тем как начать писать своё первое OpenGL приложение, рекомендую узнать какие версии поддерживает ваш драйвер(сделать это можно на сайте вендора вашей видеокарты) и обновить драйвер до последней версии.
Устройство OpenGL
OpenGL можно сравнить с большим конечным автоматом, который имеет множество состояний и функций для их изменения. Под состоянием OpenGL в основном имеют ввиду контекст OpenGL. Во время работы с OpenGL мы будем проходить через несколько меняющих состояния функций, которые будут менять контекст, и выполняющие действия в зависимости от текущего состояния OpenGL.
Например, если мы перед отрисовкой передадим OpenGL команду использовать линии вместо треугольников, то OpenGL все последующие отрисовки будет использовать линии, пока мы не изменим эту опцию, или не поменяем контекст.
Объекты в OpenGL
Библиотеки OpenGL написаны на C и имеют многочисленные API к ним для разных языков, но тем не менее это C библиотеки. Множество конструкций из языка С не транслируются в высокоуровневые языки, поэтому OpenGL был разработан с использованием большого количества абстракций, одной из этих абстракций являются объекты.
Объект в OpenGL — это набор опций, который определяет его состояние. Любой объект в OpenGL можно описать его (id) и набором опций, за который он отвечает. Само собой, у каждого типа объектов свои опции и попытка настроить несуществующие опции у объекта приведёт к ошибке. В этом кроется неудобство использования OpenGL: набор опций описывается C подобной структурой идентификатором которого, зачастую, является число, что не позволяет программисту найти ошибку на этапе компиляции, т.к. ошибочный и правильный код семантически неотличимы.
С таким кодом вы будете сталкиваться очень часто, поэтому когда вы привыкнете, что это похоже на настройку конечного автомата, вам станет намного проще. Данный код лишь показывает пример того, как работает OpenGL. В последствии будут представлены реальные примеры.
Но есть и плюсы. Основная фишка этих объектов состоит в том, что мы можем объявлять множество объектов в нашем приложении, задавать их опции и когда бы мы не запускали операции с использованием состояния OpenGL мы можем просто привязать объект с нашими предпочитаемыми настройками. К примеру этом могут быть объекты с данными 3D модели или нечто, что мы хотим на этой модели отрисовать. Владение несколькими объектами позволяет просто переключаться между ними в процессе отрисовки. С таким подходом мы можем сконфигурировать множество объектов нужных для отрисовки и использовать их состояния без потери драгоценного времени между кадрами.
Чтобы начать работать с OpenGL нужно познакомиться с несколькими базовыми объектами без которых мы ничего не сможем вывести на экран. На примере этих объектов мы поймём как связывать данные и исполняемые инструкции в OpenGL.
Базовые объекты: Шейдеры и шейдерные программы.=
Shader — это небольшая программа которая выполняется на графическом ускорителе(GPU) на определённом этапе графического конвейера. Если рассматривать шейдеры абстрактно, то можно сказать, что это этапы графического конвейера, которые:
Но как же выглядит графический конвейер? Очень просто, вот так:
Пока в этой схеме нас интересует только главная вертикаль, которая начинается с Vertex Specification и заканчивается на Frame Buffer. Как уже говорилось ранее, каждый шейдер имеет свои входные и выходные параметры, которые отличаются по типу и количеству параметров.
Кратко опишем каждый этап конвейера, чтобы понимать, что он делает:
| |
Шейдеры OpenGL пишутся на специальном С-подобном языке GLSL из которого они компилируются и линкуются в шейдерную программу. Уже на данном этапе кажется, что написание шейдерной программы это крайне трудоёмкое занятие, т.к. нужно определить 5 ступеней графического конвейера и связать их воедино. К большому счастью это не так: в графическом конвейере по умолчанию определены шейдеры тесселяции и геометрии, что позволяет нам определить всего два шейдера — вершинный и фрагментный (иногда его назвают пиксельным шейдером). Лучше всего рассмотреть эти два шейдера на классическом примере:
Эти два простых шейдера ничего не вычисляют лишь передают данные дальше по конвейеру. Обратим внимение как связаны вершинный и фрагментный шейдеры: в вершинном шейдере объявлена out переменная Color в которую будет записан цвет после выполнения главной функции, в то время как в фрагментном шейдере объявлена точно такая же переменная с квалификатором in, т.е. как и описывалось раньше фрагментный шейдер получает данные из вершинного посредством нехитрого прокидывания данных дальше через конвейер (но на самом деле не всё так просто).
Замечание: Если в фрагментном шейдере не объявить и не проинициализировать out переменную типа vec4, то на экран ничего выводиться не будет.
Внимательные читатели уже заметили объявление входных переменных типа vec3 со странными квалификаторами layout в начале вершинного шейдера, логично предполагать что это входные данные, но откуда нам их взять?
Базовые объекты: Буферы и Вершинные массивы
Я думаю не стоит объяснять что такое буферные объекты, лучше рассмотрим как создать и заполнить буффер в OpenGL.
Ничего сложно в этом нет, привязываем сгенереный буффер к нужному таргету (позже узнаем к какому) и загружаем данные указывая их размер и тип использования.
GL_STATIC_DRAW — данные в буфере изменяться не будут.
GL_DYNAMIC_DRAW — данныe в буфере будут изменяться, но не часто.
GL_STREAM_DRAW — данные в буфере будут изменяться при каждом вызове отрисовки.
Отлчно, теперь в памяти GPU расположенные наши данные, скомпилирована и слинкована шейдерная программа, но остаётся один нюанс: как программа узнает откуда брать входные данные для вершинного шейдера? Данные мы загрузили, но никак не указали откуда шейдерной программе их брать. Эту задачу решает отдельный тип объектов OpenGL — вершинные массивы.
Как и с буферами вершинные массивы лучше рассмотреть на примере их конфигурации
Создание вершинных массивов ничем не отличается от создания других OpenGL объектов, самое интересное начинается после строчки: Вершинный массив (VAO) запоминает все привязки и конфигурации проводимые с ним, в том числе и привязывание буферных объектов для выгрузки данных. В данном примере такой объект всего один, но на практике их может быть несколько. После чего производится конфигурация вершинного атрибута с определённым номером:
Всё теперь мы готовы отрендерить наше первое изображение
Не забудьте привязать VAO и шейдерную программу перед вызовом отрисовки.
Если вы всё сделали правильно, то вы должны получить вот такой результат:
Результат впечатляет, но откуда в треугольнике градиентная заливка, ведь мы указали всего 3 цвета: красный, синий и зелёный для каждой отдельной вершины? Это магия шейдера растеризации: дело в том, что во фрагментный шейдер попадает не совсем то значение Color которое мы установили в вершинном. Вершин мы передаём всего 3, но фрагментов генерируется намного больше (фрагментов ровно столько же сколько закрашенных пикселей). Поэтому для каждого фрагмента берётся среднее из трёх значений Color в зависимости от того насколько близко он находится к каждой из вершин. Это очень хорошо прослеживается у углов треугольника, где фрагменты принимают то значение цвета, которое мы указали в вершинных данных.
Забегая чуть вперёд скажу, что текстурные координаты передаются точно так же, что позволяет с лёгкостью накладывать текстуры на наши примитивы.
Думаю на этом стоит закончить данную статью, самое сложное уже позади, но самое интересное только начинается. Если у вас есть вопросы или вы увидели ошибку в статье, напишите об этом в комментариях, я буду очень признателен.
В следующей статье мы рассмотрим трансформации, узнаем о unifrom переменных и научимся накладывать текстуры на примитивы.
Контекст рендеринга что это
Содержание
Введение
Что такое OpenGL
Типы данных
Контекст рендеринга
Проблемы, зависимые от формата пикселя
Другие типы данных
Советы по использованию типов данных
Синтаксис команд
Заключение
Введение
Привет, в этом уроке я хотел бы познакомить вас поближе с OpenGL. Большая часть этого урока состоит из голой теории, но которая очень важна. Поэтому не стоит расстраиваться, если в конце этого урока вы не увидите демонстрацию какого-либо красивого графического объекта. Но, я вам обещаю, рисование начнется со следующих уроков.
Что такое OpenGL?
Чтобы ответить на этот вопрос, мы должны знать, что OpenGL – это аббревиатура (Open Graphics Library – открытая графическая библиотека). Слово Open означает «открытая». То есть, стандарт OpenGL, с появлением новых технологий, позволяет отдельным производителям добавлять в библиотеку функциональность через механизм расширений. Расширения распространяются с помощью двух составляющих: заголовочный файл, в котором находятся прототипы новых функций и констант, а также драйвер устройства, поставляемого разработчиком.
Слово Graphics – означает «графическая», то есть OpenGL предназначен для создания 2-ух и 3-ёх мерной графики. OpenGL владеет относительно маленьким набором команд, порядка 250 отдельных команд (около 200 в ядре OpenGL и около 50 в GLU), что позволяет их быстро изучить. Но в связи с этим в OpenGL нет функций для рисования комплексных объектов, таких как птица или автомобиль. Такие объекты строятся из небольшого набора, так называемых, примитив: точек (вершин), линий, треугольников и многоугольников.
Слово Library – означает «библиотека», то есть OpenGL это программный интерфейс приложения (Application Programming Interface – API). Таким образом, когда мы говорим «программа основана на OpenGL» или «приложение OpenGL», то мы подозреваем, что приложение написано на каком-то языке программирования (например, на Delphi) и это приложение вызывает функции OpenGL из одной или несколько библиотек OpenGL. Ядро OpenGL находится в библиотеке opengl32.dll, расположенной в системном каталоге Windows. Так же на большинстве платформ библиотека OpenGL сопровождается библиотекой GLU (OpenGL Utility Library – набор программ OpenGL), которая располагается в файле glu32.dll также в системном каталоге. Эта библиотека является набором служебных функций для моделирования кривых и поверхностей, а также имеет множество инструментов, таких как вычислители и NURBS.
Стоит также отметит, что OpenGL не зависит от платформы. Теоретически вы можете использовать OpenGL в любой операционной системе и запускать приложения с OpenGL на любой платформе. Однако это влечет за собой недостаток, определенные вещи, как управление окнами, клавиатурой или мыши, исключены из библиотеки. Об этих вещах мы должны позаботиться сами. К счастью, управление окнами и организацию пользовательского ввода можно реализовать с помощью Delphi.
Типы данных
Контекст рендеринга
Как мы уже знаем OpenGL не зависит от платформы и для обеспечения этой независимости, в ней определены собственные типы. Одним из самых важных типов, который используется в OpenGL это контекст рендерига (контекст визуализации), он обозначается как HGLRC. Контекст рендеринга содержит всю необходимую информацию, которая описывает область рисования и связанные с ней ресурсы. Эта информация содержит указания к использованию формата пикселей, размер области рисования (высота, ширина, пропорции), а также указания для буфера цвета, трафарета, буфера глубины и прозрачности. Кроме того, контекст рендеринга содержит общую информацию состояния, такую как тип и толщина изображаемых линий, используемые текстуры, а так же множество других указаний.
Описывающие процедуры создания контекста редеринга в этом разделе только под Windows. Под Linux детали отличаются и мы их изучим позже. Чтобы начать работать с OpenGL, необходимо в первую очередь указать контекст устройства (HDC), потому что, контекст рендеринга связывается с контекстом устройства. Так как, контексты рендеринга и устройства связаны, то они имеют одинаковый формат пикселей. Не смотря, что формат пикселей у этих контекстов одинаковый, контекст рендеринга и контекст устройство не одно и то же. Контекст устройства содержит информацию, относящуюся к GDI Windows. Контекст рендеринга содержит информацию, относящуюся к OpenGL. Таким образом, контекст рендеринга OpenGL является «портом», через который проходят все команды OpenGL, соединяя OpenGL с Windows. У каждого потока, который делает вызов команд OpenGL, должен быть текущий контекст рендеринга. Если приложение делает вызовы команд OpenGL из потока, у которого отсутствует контекст рендеринга, то ничего не происходит. Окно может иметь несколько контекстов рендеринга, но поток может иметь только один текущий (активный) контекст рендеринга, а контекст рендеринга может быть актуальным только к одному потоку. Вот пример создания контекста рендеринга с помощью dglOpenGL.pas
Var
DC : HDC;
RC : HGLRC;
TfrmMain.FormCreate procedure (Sender : TObject);
Begin
DC := GetDC(Handle) //получаем контекст устройства
RC := CreateRenderContext(DC, //контекст рендеринга
[opDoubleBuffered], /опции
32, //глубина цвета
24, //сколько битов зарезервировано для буфера глубины
0, //сколько битов зарезервировано для теста трафарета
0, //сколько бит сохраняется в буфере накопления
0, //сколько бит сохраняется во вспомогательном буфере 0); //определяет количество слоев
ActivateRenderingContext(DC,RC); //активация и связывание контекстов рендеринга и утсройства
End;
В процедуре CreateRenderContext, первый парметр указывает контекст устройства, с которым связывается контекст рендеринга. Например, контекст Формы или контекст Панели. В зависимости где позже будет отображаться графика OpenGL.
Второй параметр, указывает опции. Например: opDoubleBuffered указывает, что будет использоваться двойная буферезация.
Третий параметр указывает глубину цвета, в этом примере стоит 32. Это означает, что для 4 цветовых каналов (красного, зеленого, синего и альфа (прозрачность)) находятся в распоряжение 32/4=8 бит (1 байт). Следовательно, для каждого канала можно использовать 256 градаций. Таким образом, всего можно получить 256^4 = 4 294 967 296 цветов.
Четвертый параметр указывает, сколько бит резервируется для буфера глубины. Здесь 24 бит, это значит, что возможно от 0 до 2^24 = 16,7 млн. Чем выше значение, чем тоньше и точнее происходит тест глубины
Пятый параметр указывает количество бит для использования теста трафарета (маскирование частей экрана).
Шестой параметр указывает, сколько бит может быть сохранено в буфере накопления.
Седьмой показывает, сколько бит может быть сохранено во вспомогательном буфере.
Восьмой определяет количество слоев.
Проблемы, зависимые от формата пикселя
Известная проблема, связана с тем, что контекст рендеринга связан с контекстом устройства и формат пикселей устанавливается только один раз, поэтому вы должны знать заранее какие значения формата пикселя подходят для создаваемого контекста устройства. Чтобы избавится от этой проблемы, часто необходимо создать тестовый контекст устройства на спрятанном окне, на котором создается тестовый контекст рендеринга. Эта проблема часто возникает при мультисэмплинге (сглаживании), поскольку сглаживание требует соответствующего расширения или способности оборудования.
Другие типы данных
Все типы данных OpenGL начинаются с GL, после чего указывается соответствующий тип данных на C (byte, short,int…). Перед некоторыми имеется u, что указывает на тип данных без знака. В таблице приведены типы данных OpenGL и соответствующие типы данных на Delphi. Правда не у всех типов OpenGL есть соответствие для Delphi. Например, GLclampf – вещественное число в пределах от нуля до единицы, в Delphi он определен как Single. Поэтому в программах устанавливают «ручную» проверку на вхождение величины такого типа в требуемый диапазо Таблица 1. Типы данных OpenGL и соответствующие типы на Delphi.
Контексты отрисовки
Контекст визуализации OpenGL — это порт, через который проходят все команды OpenGL. Каждый поток, выполняющий вызовы OpenGL, должен иметь текущий контекст отрисовки. контексты отрисовки связывают OpenGL с системными окнами Windows.
приложение указывает контекст устройства Windows при создании контекста отрисовки. Этот контекст визуализации подходит для рисования на устройстве, на которое ссылается заданный контекст устройства. В частности, контекст визуализации имеет тот же формат пикселей, что и контекст устройства. Дополнительные сведения см. в разделе Визуализация функций контекста.
Несмотря на эту связь, контекст визуализации не совпадает с контекстом устройства. Контекст устройства содержит сведения, относящиеся к компоненту Graphics (GDI) Windows. Контекст визуализации содержит сведения, относящиеся к OpenGL. Контекст устройства должен быть явно указан в вызове GDI. В вызове OpenGL контекст визуализации является неявным. Перед созданием контекста отрисовки необходимо задать формат пикселей контекста устройства.
Поток, выполняющий вызовы OpenGL, должен иметь текущий контекст отрисовки. Если приложение выполняет вызовы OpenGL из потока, в котором отсутствует текущий контекст отрисовки, ничего не происходит; вызов не оказывает никакого влияния. Приложение обычно создает контекст отрисовки, устанавливает его как текущий контекст визуализации потока, а затем вызывает функции OpenGL. После завершения вызова функций OpenGL приложение отделяет контекст визуализации от потока, а затем удаляет контекст визуализации. Окно может одновременно рисовать несколько контекстов отрисовки, но поток может иметь только один текущий активный контекст визуализации.
Текущий контекст визуализации имеет связанный контекст устройства. Этот контекст устройства не должен совпадать с контекстом устройства, который использовался при создании контекста визуализации, но должен ссылаться на то же устройство и иметь тот же формат пикселей.
Поток может иметь только один текущий контекст отрисовки. Контекст отрисовки может быть текущим только для одного потока.
Руководство по программированию OpenGL для Mac
Работа с рендерингом контекстов
Контекст рендеринга является контейнером для получения информации состояния. Когда Вы определяете контекст рендеринга как текущий контекст рендеринга, последующие команды OpenGL изменяют состояние того контекста, объекты, присоединенные к тому контексту или drawable объекту, связанному с тем контекстом. По мере необходимости, когда контекст рендеринга фактически присоединен к drawable объекту, фактические поверхности получения никогда не принадлежат контексту рендеринга, но создаются. Можно присоединить многократные контексты рендеринга к тем же поверхностям получения. Каждый контекст поддерживает свое собственное состояние получения.
Обновите контекст рендеринга когда изменения средства рендеринга или геометрии
Изменение средства рендеринга может произойти, когда пользователь перетаскивает окно от одного дисплея до другого или когда дисплей присоединен или демонтирован. Изменения геометрии происходят, когда режим отображения изменяется или когда окно изменено или перемещено. Если Ваше приложение использует NSOpenGLView объект поддержать контекст, это автоматически обновляется. Приложение, создающее пользовательское представление для содержания контекста рендеринга, должно отследить надлежащие системные события и обновить контекст, когда изменяются геометрия или дисплей.
Обновление контекста рендеринга уведомляет его относительно изменений геометрии; это не сбрасывает содержание. Вызов функции обновления обновляет присоединенные drawable объекты и гарантирует, что средство рендеринга должным образом обновляется для любых виртуальных экранных изменений. Если Вы не обновляете контекст рендеринга, можно видеть артефакты рендеринга.
Ваше приложение должно обновить контекст рендеринга после системного события, но прежде, чем нарисовать к контексту. Если drawable объект изменен, можно хотеть выпустить a glViewport команда, чтобы гарантировать, что содержание масштабируется должным образом.
Примечание: Некоторые события системного уровня (такие как изменения режима отображения), которые требуют обновления контекста, могли перераспределить буферы контекста; таким образом необходимо перерисовать всю сцену после всех обновлений контекста.
Важно, чтобы Вы не обновляли более, чем необходимые контексты рендеринга. Ваше приложение должно реагировать на события системного уровня и уведомления вместо того, чтобы обновить каждый кадр. Например, Вы захотите реагировать на перемещение окна и изменить размеры операций и вывести на экран изменения конфигурации, такие как изменение глубины цвета.
Отслеживание изменений средства рендеринга
Каждый специфичный для Apple OpenGL, APIs имеет функцию, возвращающую текущее виртуальное экранное число:
currentVirtualScreen метод NSOpenGLContext класс
Виртуальное экранное число представляет индекс в списке виртуальных экранов, установленных в частности для объекта формата пикселя, используемого для контекста рендеринга. Число уникально для списка, но бессмысленно иначе.
Обновление контекста рендеринга для пользовательского представления какао
Если Вы разделяете на подклассы NSView вместо того, чтобы использовать NSOpenGLView класс, Ваше приложение должно обновить контекст рендеринга. Это вследствие незначительных различий между событиями, обычно обработанными NSView класс и обработанные NSOpenGLView класс. Какао не вызывает a reshape метод для NSView класс, когда размер изменяется, потому что тот класс не экспортирует a reshape метод для переопределения. Вместо этого необходимо выполнить, изменяют операции непосредственно в Вашем drawRect: метод, ища изменения в поле зрения ограничивает до рисования содержания. Используя этот подход обеспечивает результаты, которые эквивалентны использованию reshape метод NSOpenGLView класс.
Это немного более сложно для обработки изменений в конфигурации дисплея. Для этого необходимо зарегистрироваться для уведомления NSApplicationDidChangeScreenParametersNotification через NSApplication класс. Это уведомление отправляется каждый раз, когда конфигурация любого из дисплеев, присоединенных к компьютеру, изменяется (или программно или когда пользователь изменяет настройки в интерфейсе).
Параметры контекста изменяют поведение контекста
Контекст рендеринга имеет множество параметров, которые можно установить для удовлетворения потребностям получения OpenGL. Некоторые самые полезные, и часто пропускаемый, параметры контекста обсуждены в этом разделе: интервал подкачки, поверхностная непрозрачность, порядок рисования поверхности и управление заднего размера буфера.
Каждый специфичный для Apple OpenGL APIs обеспечивает подпрограмму для установки и получения параметров контекста рендеринга:
setValues:forParameter: метод NSOpenGLContext класс берет в качестве параметров список значений и список параметров.
CGLSetParameter функция берет в качестве параметров контекст рендеринга, константа, указывающая опцию и значение для той опции.
Некоторые параметры должны быть позволены для их значений вступить в силу. Справочная документация для параметра указывает, должен ли быть включен параметр. Посмотрите Ссылку класса NSOpenGLContext и Ссылку CGL.
Интервал подкачки позволяет приложению синхронизировать обновления с экранным обновлением
Можно использовать следующие константы, чтобы указать установку значения интервала подкачки:
Перечисление 7-2 Используя CGL для установки синхронизации
Поверхностная непрозрачность указывает как смешения поверхности OpenGL с поверхностями позади него
Можно использовать следующие константы, чтобы указать установку поверхностного значения непрозрачности:
Перечисление 7-3 Используя CGL для установки поверхностной непрозрачности
Порядок рисования поверхности указывает позицию поверхности OpenGL относительно окна
Можно использовать следующие константы, чтобы указать установку поверхности, получающей стоимость заказа:
Перечисление 7-4 Используя CGL для устанавливания порядка рисования поверхности
Определение, происходит ли обработка вершины и фрагмента на GPU
Важный: Несмотря на то, что можно выполнить эти запросы в любое время, иметь в виду, что такие запросы вызывают проверку внутреннего состояния, которая может повлиять на производительность. Для лучшей производительности не используйте эти запросы в своем цикле получения. Вместо этого выполните запросы один раз в инициализации или время установки контекста, чтобы определить, использует ли OpenGL CPU или GPU для обработки, и затем действуйте соответственно в Вашем цикле получения.
Перечисление 7-5 Используя CGL, чтобы проверить, обрабатывает ли GPU вершины и фрагменты
Управление Обратным размером буфера
Обычно, задний буфер является тем же размером как окно, или просмотрите это, это вовлечено, и это изменяет размер, когда окно или представление изменяют размер. Для окна, размер которого 720 [×] пиксели, OpenGL назад буферизует, измерен для соответствия. Если окно растет до 1 024 [×] 768 пикселей, например, тогда задний буфер изменен также. Если Вы не хотите это поведение, используйте задний параметр управления размером буфера.
Используя этот параметр фиксирует размер заднего буфера и позволяет системе масштабировать изображение автоматически, когда это перемещает данные в переменный буфер размера (см. рисунок 7-1 ). Размер заднего буфера остается фиксированным в размере, который Вы устанавливаете независимо от того, изменено ли изображение для отображения больше на экране.
Можно использовать следующие константы, чтобы указать установку размера поддержки поверхности:
Перечисление 7-6 Используя CGL для установки назад управления размером буфера
Совместное использование рендеринга ресурсов контекста
Контексту рендеринга не принадлежат рисованного объекты, присоединенные к нему, который оставляет открытым опция для совместного использования. Рендеринг контекстов может совместно использовать ресурсы и может быть присоединен к тому же drawable объекту (см. рисунок 7-2 ), или к различным drawable объектам (см. рисунок 7-3 ). Вы устанавливаете контекст, совместно использующий — или больше чем с одним drawable объектом или с другим контекстом — в то время, когда Вы создаете контекст рендеринга.
Контексты могут совместно использовать объектные ресурсы и их связанное объектное состояние путем указания совместно используемого контекста во время создания контекста. Совместно используемые контексты совместно используют все объекты текстуры, дисплейные списки, программы вершины, программы фрагмента, и буферизуют объекты, создаваемые прежде и после того, как будет инициироваться совместное использование. Состояние объектов также совместно используется, но не другое состояние контекста, такое как текущий цвет, настройки координаты текстуры, матрица и настройки освещения, состояние растеризации и параметры среды текстуры. Необходимо копировать изменения состояния контекста как требуется, но необходимо установить отдельные объекты только один раз.
Рисунок 7-2 Совместно используемые контексты, присоединенные к тому же drawable объекту 
При создании контекста OpenGL можно определять другой контекст, объектные ресурсы которого Вы хотите совместно использовать. Все совместное использование является коллегой для пиринга. Когда последний совместно использующий контекст ресурс выпущен, совместно используемые ресурсы считаются на ссылку и таким образом сохраняются, пока явно не выпущено или.
Не каждый контекст может быть совместно использован с любым контекстом. Оба контекста должны совместно использовать тот же профиль OpenGL. Необходимо также гарантировать, чтобы оба контекста совместно использовали тот же набор средств рендеринга. Вы удовлетворяете эти требования путем обеспечения, что каждый контекст использует тот же виртуальный экранный список, с помощью любого из следующих методов:
Используйте тот же объект формата пикселя создать все контексты рендеринга, которые Вы хотите совместно использовать.
Создайте объекты формата пикселя с помощью атрибутов, сужающих выбор к единственному дисплею. Эта практика гарантирует, что виртуальный экран идентичен для каждого объекта формата пикселя.
Рисунок 7-3 Совместно используемые контексты и больше чем один drawable объект 
Установка совместно использованных контекстов рендеринга является очень прямой. Каждый специфичный для Apple OpenGL API предоставляет функциям опцию указать контекст для совместного использования в его подпрограмме создания контекста:
Перечисление 7-7 гарантирует тот же виртуальный экранный список при помощи того же объекта формата пикселя для каждого из совместно используемых контекстов.
Перечисление 7-8 гарантирует тот же виртуальный экранный список при помощи того же объекта формата пикселя для каждого из совместно используемых контекстов.
