Здравствуйте, c-smile, Вы писали:
CS>Вышеизложенное означает что GDI в принципе не может иметь per primitives hardware accelerated drawing.
CS>Т.е. DrawLine(hdc, ...) это банальный Брезенхем исполняемый CPU и изменяющий RAM. Т.е. этот механизм есть O(N) где N это количество пикселей на экране. Т.е. sucks on high-dpi monitors. CS>В Direct2D, DirectX, OpenGL же DrawLine() это (условно) посылка quad (четырех координат) на GPU для отрисовки его процессорами (shaders, etc). CS>Т.е. этот механизм для CPU есть O(1) complex — на зависит от размера экрана.
Хорошо, тогда почему WPF это abandoware ? В микрософте пилят нативные аналоги на DirectX, Direct2D или что ?
Причём тут шина? Она всего лишь предоставляет периферийным устройствам набор универсальных методов (прерывания, порты ввода-вывода, прямой доступ к памяти) для обмена данными с процессором. А какие из этих методов использовать и с какой целью определяет уже конечное устройство, а не шина (скажем у сетевой карты тоже DMA в полный рост и тоже совсем не в роли экранного буффера), так что разбираться надо с конкретным устройством (видеокартой) и его драйверами (интерфейсом к которым как раз и являются OpenGL/DirectX).
_>>Что же касается портов ввода/вывода и прерываний, то они безусловно так же имеются в PCI, только не очень понятно какое это имеет отношение к обсуждаемой теме. ) O>Нет, речь именно о memory mapped IO space O>Или вот педивикия https://en.wikipedia.org/wiki/Memory-mapped_I/O
Так где речь идёт именно о портах ввода-вывода? Или ты утверждаешь, что все данные в видеокарту загружаются через этот медленный и приводящий к нагрузке на CPU механизм? ))) Не следует путать факт наличия возможности и его реального использования...
Здравствуйте, alex_public, Вы писали:
_>glBegin в 2017-ом году? Серьёзно?
Да пофигу. Я выдрал тот код из первой же выдачи в гугле.
CS>>А вообще рекомендую глянуть на NanoVG, там все в общем-то тривиально.
_>Да я как бы и сам без проблем могу написать функцию, рисующую линию на экране с помощью opengl, но тривиальной она не будет в любом случае.
Про тривиальность именно написания речи нигде не было. Мы говорим про computational complexity вывода графики.
Использовать CPU алгоритмы со сложностью O(N) в desktop UI в 21 веке уже нельзя. Т.е. GDI,GDI+,AGG (при всей моей любви к последней) уже всё —
количество пикселей на экранах 96dpi и 300dpi (retina) отличается на порядок — CPU не вытягивают.
Собственно внедрение high-dpi мониторов (которые были уже давно) тормозилось именно отсутствием должной математики (в том числе).
Здравствуйте, Ikemefula, Вы писали:
I>Если рефакторинг работает долго, как ты сказал
Ох дюд. Хватит мучать сову.
I>Всего 5 лет назад было модным "ускорять" MS VS путём включения флажка largeaddressaware. Это доступно только если OS — 64 бита.
Никогда такой хренотенью не занимался.
I>Начинаем сначала: "прорыв в ИДЕ случился благодаря SSD и x64." I>Твоя реплика "Угу, году так в 2003м, если не раньше." I>И как теперь понимать твои высказывания ?
Это был сарказм. Потому что в 2003м SSD ещё не было, x64 тока появился и массово ни у кого не было.
Но IDE уже начали обрастать серьёзными функциями. Не сами так с расширениями.
I>Idea давно уже 64 бита.
И помогло это ей?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>>вижла в 2003м была 32х битная, а это значит 2гб на процесс и кердык. CC>>Не вижу связи. У меня до сих пор вижуалка 32битная
НС>Ее 64-битной вообще в природе не бывает и в обозримом будущем не будет.
Кстати, а почему? Не осилили переход? Или в колбасе потребности нет?
Здравствуйте, netch80, Вы писали:
N>Кстати, а почему? Не осилили переход? Или в колбасе потребности нет?
Официально — больше второе (лень искать ссылку). По факту — первое (огромное количество legacy, которое никто переколбашивать не будет).
Печальная история началась при разработке 7 студии. Если кто не в курсе — она была написана с нуля. И был во главе сего некий архитект, который придумал мегаархитектуру на СОМ, которая оказалась настролько инвазивной, что намертво прибила все попытки что то сделать с ее ядром.
Здравствуйте, Ikemefula, Вы писали:
I>>>вижла в 2003м была 32х битная, а это значит 2гб на процесс и кердык. CC>>Не вижу связи. У меня до сих пор вижуалка 32битная I>Всего 5 лет назад было модным "ускорять" MS VS путём включения флажка largeaddressaware. Это доступно только если OS — 64 бита.
Слышал звон ...
1) Флажок включается при компиляции в ехе или утилиткой. Для студии он уже включен.
2) Включали не флажок, а опцию ОС, ключем загрузчика.
3) Опция эта нужна только для 32-хбитных ОС. Для 64-битных без нее у 32-битных приложений доступно больше, чем с ним в 32 битах (все системные dll заменены стабами).
Здравствуйте, c-smile, Вы писали:
_>>Да я как бы и сам без проблем могу написать функцию, рисующую линию на экране с помощью opengl, но тривиальной она не будет в любом случае. CS>Про тривиальность именно написания речи нигде не было. Мы говорим про computational complexity вывода графики. CS>Использовать CPU алгоритмы со сложностью O(N) в desktop UI в 21 веке уже нельзя. Т.е. GDI,GDI+,AGG (при всей моей любви к последней) уже всё — CS>количество пикселей на экранах 96dpi и 300dpi (retina) отличается на порядок — CPU не вытягивают.
Это безусловно верно. Но я намекаю на другой нюанс. Что если считать затраты на рисование с помощью шейдеров по честному (т.е. учитывать не только конечную функцию, инициирующую рисование, но и все подготовительные этапы), то их честный O(1) во многих случаях может оказаться больше чем O(N) из тупого рисования в память.
CS>Собственно внедрение high-dpi мониторов (которые были уже давно) тормозилось именно отсутствием должной математики (в том числе).
Ну вообще то dpi имеет довольно слабое отношение к числу пикселей на экране. Скажем у больших 4K телевизоров очень маленький dpi, но при этом очень много пикселей.
Далее, если уж говорить про dpi, то тут надо ещё понимать, что во многих случаях высокий dpi имеет только маркетинговый смысл, т.к. его использование выходит за реальные возможности человеческого глаза по распознаванию углового размера — чистый развод покупателей. Разве что есть небольшой смысл на платформах не осиливших нормальное сглаживание шрифтов (типа OSX) — там тогда появляется эффект "физического" сглаживания шрифтов прямо в глазе (набор пикселей видится как один сглаженный). А в большинстве случаев это развод маркетолагами на большие цифры (у нас больше dpi чем у конкурентов и пофиг что человеческий глаз не может увидеть разницу на предполагаемом рабочем расстояние), так что не вижу ничего плохого в сдерживание этого бреда.
А вот высокие разрешения (4K и далее) — это действительно очень классно (если конечно имеются соответствующие источники контента), т.к. увеличивает детализацию изображений (только для того, чтобы их реально разглядеть нужен и экран большого физического размера). И тут действительно есть проблемы с производительностью. Только вот они есть и у GPU в том числе (см. например какие нужные видеокарты для современных игр на экране в 4K).
Здравствуйте, 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 то вся нагрузка скатывается обратно на проц.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, c-smile, Вы писали:CS>>Использовать CPU алгоритмы со сложностью O(N) в desktop UI в 21 веке уже нельзя. Т.е. GDI,GDI+,AGG (при всей моей любви к последней) уже всё — CS>>количество пикселей на экранах 96dpi и 300dpi (retina) отличается на порядок — CPU не вытягивают.
_>Это безусловно верно. Но я намекаю на другой нюанс. Что если считать затраты на рисование с помощью шейдеров по честному (т.е. учитывать не только конечную функцию, инициирующую рисование, но и все подготовительные этапы), то их честный O(1) во многих случаях может оказаться больше чем O(N) из тупого рисования в память.
Еще раз, мы говорим про задачу UI rendering. Т.е. 2D в основном. Скажем за минимальный джентльменский набор можно использовать <canvas>
Что в этом случае значит по-честному? И где там ты видишь O(N) complexity?
Все что я могу представить это tessellation сложных shapes. Но это ни разу не O(N pixels) задача в общем случае.
CS>>Собственно внедрение high-dpi мониторов (которые были уже давно) тормозилось именно отсутствием должной математики (в том числе).
_>Ну вообще то dpi имеет довольно слабое отношение к числу пикселей на экране. Скажем у больших 4K телевизоров очень маленький dpi, но при этом очень много пикселей.
Когда говорят про high-DPI проблемы то сравнивают два монитора одного размера, скажем 21-inch, один 96 ppi второй 300 ppi. У второго пикселей в 8-10 раз больше.
_>Далее, если уж говорить про dpi, то тут надо ещё понимать, что во многих случаях высокий dpi имеет только маркетинговый смысл, т.к. его использование выходит за реальные возможности человеческого глаза по распознаванию углового размера — чистый развод покупателей.
Это к делу не относится. Тем не менее пользователи, особенно на мобильных девайсах когда экран ближе, выбирают девайсы с большим dpi. Экран ближе к глазам и 96 dpi пиксели различимы невооруженным глазом.
Notebooks там же.
Есть еще один фактор повышения быстродействия — интенсивное использование alpha канала в современных DWM.
Здравствуйте, 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 то вся нагрузка скатывается обратно на проц.
Здравствуйте, c-smile, Вы писали:
CS>Есть мнение что вы просто "не умеете это готовить".
Может быть, но из GDI удалось ~8х ускорение в сравнении с прямолинейным подходом выдавить а вот D2D до того же уровня разогнать не вышло.
CS>Мой htmlayout использовал GDI, sciter — Direct2D.
Я на sciter в своё время смотрел и не был впечатлён производительностью.
Contrasting Direct2D and GDI acceleration in Windows 7
Direct2D and GDI are both 2D immediate-mode rendering APIs and are hardware accelerated.
Справедливости ради есть оговорка:
GDI is ... accelerated on Windows 7 when the Desktop Window Manager is running and a WDDM 1.1 driver is in use
Т.е. по факту всегда.
CS> Во втором kinetic scrolling (60 FPS animation) full screen текста работает. В GDI нет, не успевает. Особенно на 200 dpi desktop monitors.
Мне ж не надо каждый кадр рендерить одно и то же, мне надо быстро нарисовать кадр с большим колвом разного чёткого текста а уже получившийся битмап потом можно скроллить как угодно.
Воткнул щас в скроллер perfcounter: BitBlt буфера, который в разы больше чем экран выполняется ~4.87 avg msec на 3440х1440, что более чем достаточно.
CS>Нет. Direct2D использует h/w acceleration font rendering в DrawGlyphRun. И для ClearType и gray scale AA. ClearType несколько другой но тем не менее.
Все D2D/DW text rendering примеры что я видел очень конкретно заикались на сравнительно небольшом колве текста в сравнении с тем, что мне было надо.
Но хуже всего было то, что на небольших размерах шрифта и стандартном DPI они рисовали плохо читаемое мыло.
Здравствуйте, Ночной Смотрящий, Вы писали:
CC>>>Не вижу связи. У меня до сих пор вижуалка 32битная I>>Всего 5 лет назад было модным "ускорять" MS VS путём включения флажка largeaddressaware. Это доступно только если OS — 64 бита.
НС>Слышал звон ... НС>1) Флажок включается при компиляции в ехе или утилиткой. Для студии он уже включен. НС>2) Включали не флажок, а опцию ОС, ключем загрузчика.
Идея понятна ? Видишь, чего автор статьи предлагает сделать ?
НС>3) Опция эта нужна только для 32-хбитных ОС. Для 64-битных без нее у 32-битных приложений доступно больше, чем с ним в 32 битах (все системные dll заменены стабами).
when your 32-bit EXE is run on a 64-bit system, it will have a 4GB address space instead of the default 2GB address space normally associated with 32-bit applications.
Здравствуйте, CreatorCray, Вы писали:
I>>Если рефакторинг работает долго, как ты сказал CC>Ох дюд. Хватит мучать сову.
Если ты отзываешь свои слова, то я конечно это принимаю
CC>Это был сарказм. Потому что в 2003м SSD ещё не было, x64 тока появился и массово ни у кого не было. CC>Но IDE уже начали обрастать серьёзными функциями. Не сами так с расширениями.
ИДЕ это продуктивити тул, принципиально он _ничего_ не меняет, исключительно продуктивность повышает. Для таких тулов, т.е. продуктивити вообще, перформанс это приоритет нумер 1.
Ты сам то подумай — нахрена нужна ИДЕ если эти серьёзные функции тормозить будут безбожно ?
I>>Idea давно уже 64 бита. CC>И помогло это ей?
Здравствуйте, CreatorCray, Вы писали:
I>>>>Тогда понятно, почему рефакторинг у CreatorCray не палит. I>>Ты отказываешься от своих слов?
CC>Вот мои слова: CC>
CC>> Refactor rename работал замечательно
А чего это ты скипнул другие свои слова ?
...но я никогда не переименовывал что то реально глобальное,
и вот еще
Такого я не делал. Думаю что долго.
Похоже, ты уже начал выбирать, где твои, а где больше не твои слова
Поделись, откуда такая оценка что долго работать будет ? В нормальной ИДЕ при наличии памяти и SSD долго работать как раз таки не будет. Find Usage работает шустро на SSD, и очень плохо — на обычном веники. Просекаешь, за счет чего прогресс произошел ?
Здравствуйте, CreatorCray, Вы писали:
CS>> Во втором kinetic scrolling (60 FPS animation) full screen текста работает. В GDI нет, не успевает. Особенно на 200 dpi desktop monitors. CC>Мне ж не надо каждый кадр рендерить одно и то же, мне надо быстро нарисовать кадр с большим колвом разного чёткого текста а уже получившийся битмап потом можно скроллить как угодно.
Этот тест показывает, что GDI не успевает. То есть, ты DirectX использовал както особенно. Может у тебя вообще WPF какой?
CC>Воткнул щас в скроллер perfcounter: BitBlt буфера, который в разы больше чем экран выполняется ~4.87 avg msec на 3440х1440, что более чем достаточно.
То есть, в твоём случае рисование шрифтов не является BottleNeck — ну нарисуешь не за 10мс, а за 100мс или даже за 500мс, что с того ? А вот когда 60fps, вот тут то и видно, кто на самом деле шрифты быстро рисует. Или успел, или нет.
