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

_>Здравствуйте, c-smile, Вы писали:

_>>>Я говорю не про какую-то свою конкретную имплентацию, а наоборот про тот факт, что без чёткого описания конкретной задачи и точного описания решения невозможно сказать какой алгоритм будет эффективнее — недостаточно знания асимптотической сложности для ответа на данный вопрос. Это и есть мой основной посыл в данной дискуссии.
CS>>Мы обсуждаем имплементацию некой абстрактной DrawLine(p1,p2, color, width) которая в случае DirectX/OpenGL есть опять же некая абстрактная FillQuad(p1,p2,p3,p4,color).
CS>>FillQuad это "атомарная" операция для DirectX и OpenGL и O(1) для CPU сколько бы там pixels не нарисовалось в результате.

_>Да, это O(1) по пикселям, но операция совсем не атомарная. Даже если посчитать, что компиляция шейдеров, их линковка, активация и запрос идентификаторов атрибутов происходит где-то заранее (т.е. у нас тупо программка умеющая только линии рисовать, без всяких эффектов, текстур и т.п. — для них то потребуется переключение на другие шейдеры), то всё равно операция не будет атомарной, т.к. потребуются как минимум отдельные шаги на создание и загрузку массива атрибутов вершин (в данном случае координат) и только потом будет отдельный шаг инициирующий рендеринг. И это ещё даже без возможности указания цвета и других возможных атрибутов (там возможно понадобятся отдельные массивы).

Да пофигу. Всё это вышеизложенное не зависит от кол-ва пикселей т.е. как ты и сказал — O(1).
Важно то что если оно рисует на 2000*1600 то и на 4000*3200 оно будет рисовать с тем же FPS (CPU consumption).

CS>>Понятно что не все Direct2D функции настолько просто переводятся в вызовы FillMesh и FillQuad. Но базовый архитектурный принцип для Direct2D это именно быть O(1) для CPU.

_>Мы же вроде уже обсудили, что факт асимптотической сложности O(1) совершенно не гарантирует, что алгоритм будет исполняться быстрее, чем O(N).

_>>>Так я как бы не против GPU. Собственно я в своих проектах всю графику рисую через OpenGL и моя основная GUI библиотека (Qt) делает аналогично. Но как раз поэтому я вполне себе в курсе того факта, что у рисования через GPU есть свои неудобные нюансы.
CS>>Нюансы (a.k.a. implementation details), да.
CS>>И кстати Qt из-за того что она/он/оно приколочено гвоздями к OpenGL будет послабже чем Direc2D/DirectX.

_>1. В Qt используется даже не OpenGL, а OpenGL ES и за счёт этого единый код отрисовки работает не только на Windows/OSX/Linux, но и на Android/iOS и даже на устройствах вообще без ОС (но с наличием OpenGL ES ускорителя).
_>2. Насчёт того, что OpenGL послебее DirectX — это мягко говоря сомнительное высказывание. Достаточно взглянуть например на такие https://www.slideshare.net/CassEveritt/approaching-zero-driver-overhead материалы (там ближе к концу есть и результаты измерений).
_>3. При этом если всё же по каким-то причинам (например у OpenGL есть некие нюансы с RDP) хочется использовать под виндой именно DirectX драйверы к карте, для этих целей у нас есть библиотечка ANGLE от Гугла, которая реализует полноценный OpenGL ES интерфейс поверх Direct3D. Эту библиотеку используют и основные браузеры и Qt (качество опции при сборке под винду) и ещё много другого серьёзного ПО. Однако в моих проектах она не пошла, потому что никакого принципиального изменения производительности от переключения на неё я не увидел, а вот некоторые специфические возможности полноценного OpenGL потерялись (например нативный OpenGL умеет многопоточную работу, когда в одних потоках идёт загрузка данных в некий контекст, а в других рендеринг в том же контексте, а в ANGLE это перестаёт работать).
_>Кстати у Skia помнится был бэкенд в виде ANGLE — можешь легко сравнить производительность с Direct2D. Да, а ещё я смотрю у Skia появился бэкенд и поверх Vulkan — в теории это должен быть быстрее всего! )

ANGLE существует потому как OpenGL (а особенно OpenGL ES) это subset DirectX функциональности. В любом случае это доп. layer который скорости не прибавляет.
DirectX работает быстрее не только из-за того что драйвера лучше но також из-за лучшей архитектуры. Stateful OpenGL это просто ужас для multithreading и pipeline интеграции.


CS>>В OpenGL какие-то проблемы с renderbuffer — offline buffered rendering в отдельных случаях нужен. Я обсуждал возможную имплементацию Push/PopLayer с Mikko Mononen (автор NanoVG), он был даже что-то сделал. Но он сказал что "OpenGL's renderbuffer sucks".

_>Просто не надо тащить в OpenGL подходы из 2D графики — оно всё же ориентируется в первую очередь на 3D и шейдеры, а не на рисование квадратиков на экране. Т.е. последнее тоже без проблем, но надо понимать как это сделать оптимальнее, а не в стиле рисований из GDI.

"не надо тащить" а приходится, это вот:

<div style="opacity:0.7">
   ... more stuff here ...
</div>

иначе как сначала в буфер отрисовать, а потом уже это буфер с opacity вывести не поучается. В результате и Skia и Qt вынуждены имплементировать две параллельные pipeline : и CPU и GPU имплементацию всех примитивов. Что- радости не добавляет. Т.е. и Skia и Qt могут внезапно из O(1) стать O(N) если "дезигнеру" transparency вступит в голову.

К слову NanoVG это чистая GPU <canvas>/2d graphics имплементация, можно сравнить со Skia и Qt по размеру.