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

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 это перестаёт работать).

CS>У sciter есть как Direct2D так и Skia(исп. OpenGL) backends — сравнивать приходится постоянно. Не думаю что Skia (google) и rasterizer в Qt как-то уж сильно отличаются.

Кстати у Skia помнится был бэкенд в виде ANGLE — можешь легко сравнить производительность с Direct2D. Да, а ещё я смотрю у Skia появился бэкенд и поверх Vulkan — в теории это должен быть быстрее всего! )

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

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

_>>Не пофигу, потому что переход в режим ядра — это весьма и весьма тяжело. И этого дела при рисование через GPU гораздо больше, чем при рисование в память (где оно собственно только одно финальное).
CS>И в том и в том случае пересылка (переход в режим ядра?) делается условно говоря один раз:
CS>- Direct2D -> пересылка vertex data (not dependent on number of pixels — O(1))
CS>- GDI -> пересылка bitmap data (dependent on number of pixels — O(N))

См. первый абзац данного сообщения — у DirectX очевидно не один раз. )

CS>У жены-орлицы понимаешь дальнозоркость, а у меня близорукость. Т.е. она видит на телевизоре "отдельные лампочки". Что-бы ей было нормально с того дивана (ака забор) его смотреть должен быть high-DPI device.
CS>Иначе телевизор надо уносить фиг знает куда чтобы "угловой размер отдельных лампочек" уменьшить. Но в этом случае я его смотреть не смогу.
CS>Т.е. high-DPI это суровая правда семейной жизни.

Хы, так если там достаточный DPI, чтобы она не видела пикселей, то в таком случае ты со своей близорукостью просто не будешь видеть половину детализации. ))) Так что это не вариант решения проблемы — надо или очки носить или корректировать зрение.