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

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

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

_>Далее, если уж говорить про dpi, то тут надо ещё понимать, что во многих случаях высокий dpi имеет только маркетинговый смысл, т.к. его использование выходит за реальные возможности человеческого глаза по распознаванию углового размера — чистый развод покупателей.

_>Разве что есть небольшой смысл на платформах не осиливших нормальное сглаживание шрифтов (типа OSX) — там тогда появляется эффект "физического" сглаживания шрифтов прямо в глазе
Угу. В маке шрифты на low DPI выглядят отвратительно. Хуже только в линуксах.

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