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

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

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

CC>Я ещё вот что добавлю.
CC>Как показал практический опыт: вывести оченьмногатекста в ~5K x ~7K px canvas, 94 DPI, font height 14 + background fill + линии для рамочек чтоб получить а-ля excel картинку на GDI получается на порядок-другой быстрее и меньше кода чем все эти новомодные Direct2D и прочая хренотень. Категория — финансы.

Есть мнение что вы просто "не умеете это готовить".

Мой htmlayout использовал GDI, sciter — Direct2D. Во втором kinetic scrolling (60 FPS animation) full screen текста работает. В GDI нет, не успевает. Особенно на 200 dpi desktop monitors.

_>>Только вот они есть и у GPU в том числе (см. например какие нужные видеокарты для современных игр на экране в 4K).
CC>Они все почему то забывают что fillrate у видюхи таки фиксированный и залить весь экран это по факту нифига не O(1). С точки зрения проца в теории выглядит конечно привлекательно — заслать команду в видюху теоретически О(1), но вот результата придётся ждать. Единственный выигрыш — в распараллеливании работы между процом и видюхой.
CC>Но если надо рисовать шрифты, и не отбитмапленные а честно, с subpixel clear type то вся нагрузка скатывается обратно на проц.

Нет. Direct2D использует h/w acceleration font rendering в DrawGlyphRun. И для ClearType и gray scale AA. ClearType несколько другой но тем не менее.