Сообщение Re[30]: Еще от 10.06.2017 10:23
Изменено 11.06.2017 17:58 vdimas
Re[30]: Еще
Здравствуйте, c-smile, Вы писали:
V>>В D2D полностью аналогично, разве что идентификаторы участников чуть другие.
CS>Ох, ну нет конечно... там только слово Direct общее, а так парадигмы совсем разные.
CS>DirectDraw это про заброс bitmaps в видео память.
Для абстракции HDC, полученной для поверхности DirectDraw, тоже выполнялось аппаратное ускорение.
CS>Как происходит primitive rasterizing на тех bitmap DirectDraw ничего не знал (можно было руками, а можно было GDI или не приведи тя хоспидя GDI+ какой использовать).
GCI+ — вообще не по теме. Это юзверская либа поверх GDI. А GDI — это драйверная технология.
GDI так же имел возможность размещать битмапы в видеопамяти.
В общем, ты сейчас вообще переврал всё что можно. ))
Любая прорисовка в буферез заднего плана начиналась с последовательности вызовов CreateCompatibleDC/CreateCompatibleBitmap. Такой битмап по-возможности создаётся в видеопамяти (пока там хватает места).
Просто нельзя было узнать — вытеснили нафик этот битмап из видеопамяти в обычную, или оно еще там. А в случае DD можно явно запросить метод IsLost.
CS>Direct2D же...
CS>ID2DRenderingTarget это не bitmap (как правило), а storage для GPU команд.
Опять мимо.
ID2DRenderingTarget — это абстракция некоего интерфейса, наподобие HDC.
Ну разве что АПИ оформлено не в процедурном стиле, а в стиле COM.
CS>Вызов ID2D1RenderTarget::DrawLine например это выполнение tessellation того отрезка с заданной stroke т.е. генерация вектора треугольников. А уж этот вектор треугольников отправляется на GPU для рисования.
Ох, мать... А какая нафик разница-то?
На момент выхода DirectDraw уже в обычном HDC давным давно применялось аппаратное ускорение на GPU, а значит, на GPU шли точно такие же данные в аналогичных сценариях в обoих случаях.
Повторюсь — там всей разницы (в твоём сценарии) в том, что DIB-битмапы в случае HDC живут в обычной памяти и их натягивание на картинку дороговато. Ну так умные люди пользовали DDB-битмапы в видеопамяти.
CS>Как ты видишь DirectDraw и Direct2D это принципиально разные вещи.
Они-то разные, ес-но. Но только не там, где ты описываешь. И уж не для тех целей, что ты описываешь.
CS>В условиях high-dpi monitors DirectDraw (bitmap на стороне CPU) это вообще не опция.
Пфф....
Показываю в три движения:
Вот прямо с этого места делай с этим битмапом что хочешь.
Хоть через GDI, хоть через IDirectDrawSurface.
Не забудь только освободить, когда не нужен станет. )
Или можно было сделать наоборот — явно создать объект IDirectDrawSurface7 нужных размеров, у того попросить DC, а у того — приаттаченный битмап к нему.
Действительно принципиальное отличие IDirectDrawSurface от DC вовсе не BitBlt (оно, считай, идентичное в обоих случаях и выполняется аппаратно, если возможно), отличия (а) в режиме приаттаченных к друг другу поверхностей — стандартный цикл рисования в заднем буфере из цепочки со сменой текущего отображаемого буфера (Flip), а так же можно было синхронизировать этот Flip с обратным ходом развёртки.
Еще в DD появилась поддержка оверлеев и их Z-ордера (б).
Обе операции позволяли резко удешевить BitBlt, вернее, позволяли вовсе без неё обходиться — в первом случае для полноэкранного, во втором случае для оконного режима. У меня на одном из старых компов в конторе был забавный глюк — полноэкранное видео шло прекрасно, а даже в небольшом окошке тормозило. А рядом такой же точно комп, только чуть другая видюха — там не тормозило ни в одном из режимов. Очевидно, что некий GetDeviceCaps давал разные ответы насчёт оверлея ))
Кароч, собсно для для этих двух основных отличий DirectDraw и создали.
CS>Условно: для отрисовки флага республики Крым на полный экран в DirectDraw ты рисуешь bitmap в CPU и пересылаешь его/её в видео память.
ИМХО, я дал достаточно вводной инфы, чтобы любой коллега смог разбраться далее самостоятельно при желании.
CS>В Direct2D же это три вызова ID2D1RenderTarget::FillRect что выливается в посылку координат шести треугольников (+ три brush) в GPU.
Тоже неверно. В Direct2D на каждый четырёхугольник посылается ровно 4 вершины ))
Причем, неважно по какому типу PrimitiveType:
— triangle strip
— triangle fan
— quads
Последние два способа в случае четырёхугольника идентичны (обход вершин по часовой или против часовой), а первый способ требует нарисовать букву Z при обходе вершин четырёхугольника.
И да. Никакие Brush не надо. Каждой вершине присваивается свой цвет. Либо всем вершинам присваивается одинаковый цвет (до посылки примитива задаётся контекст операции). Дополнительно к каждой вершине может цепляться координата битмапа.
Точно так же происходит в случае GDI при использовании аппаратного ускорения, т.е. аккурат от момента выхода Windows 98, т.е. последние лет 20. ))
CS>Разница очевидна, нет?
Эмм...
Это если не знать, а потом еще и забыть.
V>>В OpenGL аналогом является frame buffer, созданный поверх текстуры или экранного буфера (deep buffer). Т.е. во всех случаях речь идёт о массиве байт в видеопамяти.
CS>Ну можно наверное frame buffer условно обозвать DirectDraw. Но очень условно.
Разумеется, очень и очень условно, бо нельзя на самом деле. ))
Аналогом "OpenGL Frame Buffer" надо называть "DirectDraw Surface", ес-но.
CS>Аналог же Direct2D в OpenGL... Ну вот скажем NanoVG это самое близкое по смыслу...
NanoVG — пакость редкостная, криворукая и вообще по шее за такое давать надо.
Настолько неплохая там идея (стыренная из GDI) и настолько кривая реализация, что аж обидно.
Что даже кривейший убогий SFML смотрится лучше.
Ты бы эта, посмотрел бы на досуге исходник NanoVG и ужаснулся.
Я бы долго пинал автора ногами, чесслово. ))
Двойная интерпретация внутреннего кодирования примитивов, да еще под каждый вшивый маленький блок при кодировании и раскодировании автор выделяет память из кучи и тут же освобождает. Это студенческая поделка низкого кач-ва.
CS>Image: screenshot-01.png
Не надо мне этим убожеством размахивать, я наизусть его знаю.
У меня своё чуть поинтересней есть для OpenGL. ))
V>>В D2D полностью аналогично, разве что идентификаторы участников чуть другие.
CS>Ох, ну нет конечно... там только слово Direct общее, а так парадигмы совсем разные.
CS>DirectDraw это про заброс bitmaps в видео память.
Для абстракции HDC, полученной для поверхности DirectDraw, тоже выполнялось аппаратное ускорение.
CS>Как происходит primitive rasterizing на тех bitmap DirectDraw ничего не знал (можно было руками, а можно было GDI или не приведи тя хоспидя GDI+ какой использовать).
GCI+ — вообще не по теме. Это юзверская либа поверх GDI. А GDI — это драйверная технология.
GDI так же имел возможность размещать битмапы в видеопамяти.
В общем, ты сейчас вообще переврал всё что можно. ))
Любая прорисовка в буферез заднего плана начиналась с последовательности вызовов CreateCompatibleDC/CreateCompatibleBitmap. Такой битмап по-возможности создаётся в видеопамяти (пока там хватает места).
Просто нельзя было узнать — вытеснили нафик этот битмап из видеопамяти в обычную, или оно еще там. А в случае DD можно явно запросить метод IsLost.
CS>Direct2D же...
CS>ID2DRenderingTarget это не bitmap (как правило), а storage для GPU команд.
Опять мимо.
ID2DRenderingTarget — это абстракция некоего интерфейса, наподобие HDC.
Ну разве что АПИ оформлено не в процедурном стиле, а в стиле COM.
CS>Вызов ID2D1RenderTarget::DrawLine например это выполнение tessellation того отрезка с заданной stroke т.е. генерация вектора треугольников. А уж этот вектор треугольников отправляется на GPU для рисования.
Ох, мать... А какая нафик разница-то?
На момент выхода DirectDraw уже в обычном HDC давным давно применялось аппаратное ускорение на GPU, а значит, на GPU шли точно такие же данные в аналогичных сценариях в обoих случаях.
Повторюсь — там всей разницы (в твоём сценарии) в том, что DIB-битмапы в случае HDC живут в обычной памяти и их натягивание на картинку дороговато. Ну так умные люди пользовали DDB-битмапы в видеопамяти.
CS>Как ты видишь DirectDraw и Direct2D это принципиально разные вещи.
Они-то разные, ес-но. Но только не там, где ты описываешь. И уж не для тех целей, что ты описываешь.
CS>В условиях high-dpi monitors DirectDraw (bitmap на стороне CPU) это вообще не опция.
Пфф....
Показываю в три движения:
HDC wdc = GetDC(myHwnd);
HDC cdc = CreatecompatibleDC(wdc,...);
HBITMAP hbm = CreatecompatibleBitmap(cdc, ...); // создание экранного буфера в видеопамяти
SelectObject(cdc, hbm); // установили ему GDI-рисовалку
IDirectDrawSurface7 * dxSurface = NULL;
HRESULT rc = GetSurfaceFromDC(cdc, &dxSurface); // получили для него же DirectDraw-рисовалкуВот прямо с этого места делай с этим битмапом что хочешь.
Хоть через GDI, хоть через IDirectDrawSurface.
Не забудь только освободить, когда не нужен станет. )
Или можно было сделать наоборот — явно создать объект IDirectDrawSurface7 нужных размеров, у того попросить DC, а у того — приаттаченный битмап к нему.
Действительно принципиальное отличие IDirectDrawSurface от DC вовсе не BitBlt (оно, считай, идентичное в обоих случаях и выполняется аппаратно, если возможно), отличия (а) в режиме приаттаченных к друг другу поверхностей — стандартный цикл рисования в заднем буфере из цепочки со сменой текущего отображаемого буфера (Flip), а так же можно было синхронизировать этот Flip с обратным ходом развёртки.
Еще в DD появилась поддержка оверлеев и их Z-ордера (б).
Обе операции позволяли резко удешевить BitBlt, вернее, позволяли вовсе без неё обходиться — в первом случае для полноэкранного, во втором случае для оконного режима. У меня на одном из старых компов в конторе был забавный глюк — полноэкранное видео шло прекрасно, а даже в небольшом окошке тормозило. А рядом такой же точно комп, только чуть другая видюха — там не тормозило ни в одном из режимов. Очевидно, что некий GetDeviceCaps давал разные ответы насчёт оверлея ))
Кароч, собсно для для этих двух основных отличий DirectDraw и создали.
CS>Условно: для отрисовки флага республики Крым на полный экран в DirectDraw ты рисуешь bitmap в CPU и пересылаешь его/её в видео память.
ИМХО, я дал достаточно вводной инфы, чтобы любой коллега смог разбраться далее самостоятельно при желании.
CS>В Direct2D же это три вызова ID2D1RenderTarget::FillRect что выливается в посылку координат шести треугольников (+ три brush) в GPU.
Тоже неверно. В Direct2D на каждый четырёхугольник посылается ровно 4 вершины ))
Причем, неважно по какому типу PrimitiveType:
— triangle strip
— triangle fan
— quads
Последние два способа в случае четырёхугольника идентичны (обход вершин по часовой или против часовой), а первый способ требует нарисовать букву Z при обходе вершин четырёхугольника.
И да. Никакие Brush не надо. Каждой вершине присваивается свой цвет. Либо всем вершинам присваивается одинаковый цвет (до посылки примитива задаётся контекст операции). Дополнительно к каждой вершине может цепляться координата битмапа.
Точно так же происходит в случае GDI при использовании аппаратного ускорения, т.е. аккурат от момента выхода Windows 98, т.е. последние лет 20. ))
CS>Разница очевидна, нет?
Эмм...
Это если не знать, а потом еще и забыть.
V>>В OpenGL аналогом является frame buffer, созданный поверх текстуры или экранного буфера (deep buffer). Т.е. во всех случаях речь идёт о массиве байт в видеопамяти.
CS>Ну можно наверное frame buffer условно обозвать DirectDraw. Но очень условно.
Разумеется, очень и очень условно, бо нельзя на самом деле. ))
Аналогом "OpenGL Frame Buffer" надо называть "DirectDraw Surface", ес-но.
CS>Аналог же Direct2D в OpenGL... Ну вот скажем NanoVG это самое близкое по смыслу...
NanoVG — пакость редкостная, криворукая и вообще по шее за такое давать надо.
Настолько неплохая там идея (стыренная из GDI) и настолько кривая реализация, что аж обидно.
Что даже кривейший убогий SFML смотрится лучше.
Ты бы эта, посмотрел бы на досуге исходник NanoVG и ужаснулся.
Я бы долго пинал автора ногами, чесслово. ))
Двойная интерпретация внутреннего кодирования примитивов, да еще под каждый вшивый маленький блок при кодировании и раскодировании автор выделяет память из кучи и тут же освобождает. Это студенческая поделка низкого кач-ва.
CS>Image: screenshot-01.png
Не надо мне этим убожеством размахивать, я наизусть его знаю.
У меня своё чуть поинтересней есть для OpenGL. ))
Re[30]: Еще
Здравствуйте, c-smile, Вы писали:
V>>В D2D полностью аналогично, разве что идентификаторы участников чуть другие.
CS>Ох, ну нет конечно... там только слово Direct общее, а так парадигмы совсем разные.
CS>DirectDraw это про заброс bitmaps в видео память.
Для абстракции HDC, полученной для поверхности DirectDraw, тоже выполнялось аппаратное ускорение.
CS>Как происходит primitive rasterizing на тех bitmap DirectDraw ничего не знал (можно было руками, а можно было GDI или не приведи тя хоспидя GDI+ какой использовать).
GCI+ — вообще не по теме. Это юзверская либа поверх GDI. А GDI — это драйверная технология.
GDI так же имел возможность размещать битмапы в видеопамяти.
В общем, ты сейчас вообще переврал всё что можно. ))
Любая прорисовка в буферез заднего плана начиналась с последовательности вызовов CreateCompatibleDC/CreateCompatibleBitmap. Такой битмап по-возможности создаётся в видеопамяти (пока там хватает места).
Просто нельзя было узнать — вытеснили нафик этот битмап из видеопамяти в обычную, или оно еще там. А в случае DD можно явно запросить метод IsLost.
CS>Direct2D же...
CS>ID2DRenderingTarget это не bitmap (как правило), а storage для GPU команд.
Опять мимо.
ID2DRenderingTarget — это абстракция некоего интерфейса, наподобие HDC.
Ну разве что АПИ оформлено не в процедурном стиле, а в стиле COM.
CS>Вызов ID2D1RenderTarget::DrawLine например это выполнение tessellation того отрезка с заданной stroke т.е. генерация вектора треугольников. А уж этот вектор треугольников отправляется на GPU для рисования.
Ох, мать... А какая нафик разница-то?
На момент выхода DirectDraw уже в обычном HDC давным давно применялось аппаратное ускорение на GPU, а значит, на GPU шли точно такие же данные в аналогичных сценариях в обoих случаях.
Повторюсь — там всей разницы (в твоём сценарии) в том, что DIB-битмапы в случае HDC живут в обычной памяти и их натягивание на картинку дороговато. Ну так умные люди пользовали DDB-битмапы в видеопамяти.
CS>Как ты видишь DirectDraw и Direct2D это принципиально разные вещи.
Они-то разные, ес-но. Но только не там, где ты описываешь. И уж не для тех целей, что ты описываешь.
CS>В условиях high-dpi monitors DirectDraw (bitmap на стороне CPU) это вообще не опция.
Пфф....
Показываю в три движения:
Вот прямо с этого места делай с этим битмапом что хочешь.
Хоть через GDI, хоть через IDirectDrawSurface.
Не забудь только освободить, когда не нужен станет. )
Или можно было сделать наоборот — явно создать объект IDirectDrawSurface7 нужных размеров, у того попросить DC, а у того — приаттаченный битмап к нему.
Действительно принципиальное отличие IDirectDrawSurface от DC вовсе не BitBlt (оно, считай, идентичное в обоих случаях и выполняется аппаратно, если возможно), отличия (а) в режиме приаттаченных к друг другу поверхностей — стандартный цикл рисования в заднем буфере из цепочки со сменой текущего отображаемого буфера (Flip), а так же можно было синхронизировать этот Flip с обратным ходом развёртки.
Еще в DD появилась поддержка оверлеев и их Z-ордера (б).
Обе операции позволяли резко удешевить BitBlt, вернее, позволяли вовсе без неё обходиться — в первом случае для полноэкранного, во втором случае для оконного режима. У меня на одном из старых компов в конторе был забавный глюк — полноэкранное видео шло прекрасно, а даже в небольшом окошке тормозило. А рядом такой же точно комп, только чуть другая видюха — там не тормозило ни в одном из режимов. Очевидно, что некий GetDeviceCaps давал разные ответы насчёт оверлея ))
Кароч, собсно для для этих двух основных отличий DirectDraw и создали.
CS>Условно: для отрисовки флага республики Крым на полный экран в DirectDraw ты рисуешь bitmap в CPU и пересылаешь его/её в видео память.
ИМХО, я дал достаточно вводной инфы, чтобы любой коллега смог разбраться далее самостоятельно при желании.
CS>В Direct2D же это три вызова ID2D1RenderTarget::FillRect что выливается в посылку координат шести треугольников (+ три brush) в GPU.
Тоже неверно. В Direct2D на каждый четырёхугольник посылается ровно 4 вершины ))
Причем, неважно по какому типу PrimitiveType:
— triangle strip
— triangle fan
— quads
Последние два способа в случае четырёхугольника идентичны (обход вершин по часовой или против часовой), а первый способ требует нарисовать букву Z при обходе вершин четырёхугольника.
И да. Никакие Brush не надо. Каждой вершине присваивается свой цвет. Либо всем вершинам присваивается одинаковый цвет (до посылки примитива задаётся контекст операции). Дополнительно к каждой вершине может цепляться координата битмапа.
Точно так же происходит в случае GDI при использовании аппаратного ускорения, т.е. аккурат от момента выхода Windows 98, т.е. последние лет 20. ))
CS>Разница очевидна, нет?
Эмм...
Это если не знать, а потом еще и забыть.
V>>В OpenGL аналогом является frame buffer, созданный поверх текстуры или экранного буфера (deep buffer). Т.е. во всех случаях речь идёт о массиве байт в видеопамяти.
CS>Ну можно наверное frame buffer условно обозвать DirectDraw. Но очень условно.
Разумеется, очень и очень условно, бо нельзя на самом деле. ))
Аналогом "OpenGL Frame Buffer" надо называть "DirectDraw Surface", ес-но.
CS>Аналог же Direct2D в OpenGL... Ну вот скажем NanoVG это самое близкое по смыслу...
NanoVG — пакость редкостная, криворукая и вообще по шее за такое давать надо.
Настолько неплохая там идея (стыренная из GDI) и настолько кривая реализация, что аж обидно.
Что даже кривейший убогий SFML смотрится лучше.
Ты бы эта, посмотрел бы на досуге исходник NanoVG и ужаснулся.
Я бы долго пинал автора ногами, чесслово. ))
Двойная интерпретация внутреннего кодирования примитивов, да еще под каждый вшивый маленький блок при кодировании и раскодировании автор выделяет память из кучи и тут же освобождает. Это студенческая поделка низкого кач-ва.
CS>Image: screenshot-01.png
Не надо мне этим убожеством размахивать, я наизусть его знаю.
У меня своё чуть поинтересней есть для OpenGL. ))
V>>В D2D полностью аналогично, разве что идентификаторы участников чуть другие.
CS>Ох, ну нет конечно... там только слово Direct общее, а так парадигмы совсем разные.
CS>DirectDraw это про заброс bitmaps в видео память.
Для абстракции HDC, полученной для поверхности DirectDraw, тоже выполнялось аппаратное ускорение.
CS>Как происходит primitive rasterizing на тех bitmap DirectDraw ничего не знал (можно было руками, а можно было GDI или не приведи тя хоспидя GDI+ какой использовать).
GCI+ — вообще не по теме. Это юзверская либа поверх GDI. А GDI — это драйверная технология.
GDI так же имел возможность размещать битмапы в видеопамяти.
В общем, ты сейчас вообще переврал всё что можно. ))
Любая прорисовка в буферез заднего плана начиналась с последовательности вызовов CreateCompatibleDC/CreateCompatibleBitmap. Такой битмап по-возможности создаётся в видеопамяти (пока там хватает места).
Просто нельзя было узнать — вытеснили нафик этот битмап из видеопамяти в обычную, или оно еще там. А в случае DD можно явно запросить метод IsLost.
CS>Direct2D же...
CS>ID2DRenderingTarget это не bitmap (как правило), а storage для GPU команд.
Опять мимо.
ID2DRenderingTarget — это абстракция некоего интерфейса, наподобие HDC.
Ну разве что АПИ оформлено не в процедурном стиле, а в стиле COM.
CS>Вызов ID2D1RenderTarget::DrawLine например это выполнение tessellation того отрезка с заданной stroke т.е. генерация вектора треугольников. А уж этот вектор треугольников отправляется на GPU для рисования.
Ох, мать... А какая нафик разница-то?
На момент выхода DirectDraw уже в обычном HDC давным давно применялось аппаратное ускорение на GPU, а значит, на GPU шли точно такие же данные в аналогичных сценариях в обoих случаях.
Повторюсь — там всей разницы (в твоём сценарии) в том, что DIB-битмапы в случае HDC живут в обычной памяти и их натягивание на картинку дороговато. Ну так умные люди пользовали DDB-битмапы в видеопамяти.
CS>Как ты видишь DirectDraw и Direct2D это принципиально разные вещи.
Они-то разные, ес-но. Но только не там, где ты описываешь. И уж не для тех целей, что ты описываешь.
CS>В условиях high-dpi monitors DirectDraw (bitmap на стороне CPU) это вообще не опция.
Пфф....
Показываю в три движения:
HDC wdc = GetDC(myHwnd);
HDC cdc = CreatecompatibleDC(wdc,...);
HBITMAP hbm = CreatecompatibleBitmap(wdc, ...); // создание экранного буфера в видеопамяти
SelectObject(cdc, hbm); // установили ему GDI-рисовалку
IDirectDrawSurface7 * dxSurface = NULL;
HRESULT rc = GetSurfaceFromDC(cdc, &dxSurface); // получили для него же DirectDraw-рисовалкуВот прямо с этого места делай с этим битмапом что хочешь.
Хоть через GDI, хоть через IDirectDrawSurface.
Не забудь только освободить, когда не нужен станет. )
Или можно было сделать наоборот — явно создать объект IDirectDrawSurface7 нужных размеров, у того попросить DC, а у того — приаттаченный битмап к нему.
Действительно принципиальное отличие IDirectDrawSurface от DC вовсе не BitBlt (оно, считай, идентичное в обоих случаях и выполняется аппаратно, если возможно), отличия (а) в режиме приаттаченных к друг другу поверхностей — стандартный цикл рисования в заднем буфере из цепочки со сменой текущего отображаемого буфера (Flip), а так же можно было синхронизировать этот Flip с обратным ходом развёртки.
Еще в DD появилась поддержка оверлеев и их Z-ордера (б).
Обе операции позволяли резко удешевить BitBlt, вернее, позволяли вовсе без неё обходиться — в первом случае для полноэкранного, во втором случае для оконного режима. У меня на одном из старых компов в конторе был забавный глюк — полноэкранное видео шло прекрасно, а даже в небольшом окошке тормозило. А рядом такой же точно комп, только чуть другая видюха — там не тормозило ни в одном из режимов. Очевидно, что некий GetDeviceCaps давал разные ответы насчёт оверлея ))
Кароч, собсно для для этих двух основных отличий DirectDraw и создали.
CS>Условно: для отрисовки флага республики Крым на полный экран в DirectDraw ты рисуешь bitmap в CPU и пересылаешь его/её в видео память.
ИМХО, я дал достаточно вводной инфы, чтобы любой коллега смог разбраться далее самостоятельно при желании.
CS>В Direct2D же это три вызова ID2D1RenderTarget::FillRect что выливается в посылку координат шести треугольников (+ три brush) в GPU.
Тоже неверно. В Direct2D на каждый четырёхугольник посылается ровно 4 вершины ))
Причем, неважно по какому типу PrimitiveType:
— triangle strip
— triangle fan
— quads
Последние два способа в случае четырёхугольника идентичны (обход вершин по часовой или против часовой), а первый способ требует нарисовать букву Z при обходе вершин четырёхугольника.
И да. Никакие Brush не надо. Каждой вершине присваивается свой цвет. Либо всем вершинам присваивается одинаковый цвет (до посылки примитива задаётся контекст операции). Дополнительно к каждой вершине может цепляться координата битмапа.
Точно так же происходит в случае GDI при использовании аппаратного ускорения, т.е. аккурат от момента выхода Windows 98, т.е. последние лет 20. ))
CS>Разница очевидна, нет?
Эмм...
Это если не знать, а потом еще и забыть.
V>>В OpenGL аналогом является frame buffer, созданный поверх текстуры или экранного буфера (deep buffer). Т.е. во всех случаях речь идёт о массиве байт в видеопамяти.
CS>Ну можно наверное frame buffer условно обозвать DirectDraw. Но очень условно.
Разумеется, очень и очень условно, бо нельзя на самом деле. ))
Аналогом "OpenGL Frame Buffer" надо называть "DirectDraw Surface", ес-но.
CS>Аналог же Direct2D в OpenGL... Ну вот скажем NanoVG это самое близкое по смыслу...
NanoVG — пакость редкостная, криворукая и вообще по шее за такое давать надо.
Настолько неплохая там идея (стыренная из GDI) и настолько кривая реализация, что аж обидно.
Что даже кривейший убогий SFML смотрится лучше.
Ты бы эта, посмотрел бы на досуге исходник NanoVG и ужаснулся.
Я бы долго пинал автора ногами, чесслово. ))
Двойная интерпретация внутреннего кодирования примитивов, да еще под каждый вшивый маленький блок при кодировании и раскодировании автор выделяет память из кучи и тут же освобождает. Это студенческая поделка низкого кач-ва.
CS>Image: screenshot-01.png
Не надо мне этим убожеством размахивать, я наизусть его знаю.
У меня своё чуть поинтересней есть для OpenGL. ))