Привет всем!

Я программировать оконные приложения Windows (используя Windows API, а не какие-нибудь фреймворки типа MFC) учился в начале 2000-х и с тех пор не занимался этим) И вот у меня тут вопрос возник — ничего в принципах работы графической системы Windows с тех пор принципиально не поменялось случаем? Ну может там все переходит на .NET и CLR, к примеру, или еще чего? Может быть в связи с унификацией десктопных и мобильных платформ какие-то принципиальные изменения в графическую систему вносятся/будут внесены? Или принципы графической системы Windows (message loop, оконная процедура, GetMessage(), DispatchMessage() и т.д.) остались незыблемы?

Еще раз четко сформулирую вопросы:
1) Изменились ли принципы работы графической системы в современных версиях Windows по сравнению с Windows 98, Windows XP?
2) Если не изменились, то в обозримом будущем какие-то изменения предвидятся?

Здравствуйте, Максим Рогожин, Вы писали:

МР>Еще раз четко сформулирую вопросы:
МР>1) Изменились ли принципы работы графической системы в современных версиях Windows по сравнению с Windows 98, Windows XP?
МР>2) Если не изменились, то в обозримом будущем какие-то изменения предвидятся?

Нет, не особо изменилось. Говорят, что-то новое появилось в UWP. Но, что там конкретно появилось и кто этим пользуется —

Здравствуйте, Максим Рогожин, Вы писали:

МР>Привет всем!

МР>Или принципы графической системы Windows (message loop, оконная процедура, GetMessage(), DispatchMessage() и т.д.) остались незыблемы?

Да, те же.


МР>Еще раз четко сформулирую вопросы:
МР>1) Изменились ли принципы работы графической системы в современных версиях Windows по сравнению с Windows 98, Windows XP?
МР>2) Если не изменились, то в обозримом будущем какие-то изменения предвидятся?

Да изменились. GDI умирает.

Появились high-DPI мониторы. 200-300dpi против бывших 100dpi что означает увеличение кол-ва пикселей в 4-9 раз.
CPU (а GDI это CPU rasterization) уже не справляется. Поэтому графика переползает на GPU. Новые слова: Direct2D, DirectComposition, DirectWrite — это все про hardware acceleration.

Начиная с Windows 8.1 поддерживается не только multi-monitor но и multi-dpi-monitors.
Пиксели, и UI прибитый гвоздями к пиксельным сеткам — умирает. dip это наше всё нынче.

В качестве примера:

Вот Evernote с GDI UI и то же в Sciter (использует Direct2D) на high-dpi мониторе:



Видно Windows рисует каждый GDI пиксел как 4 физических пиксела — неряшливо.

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

CS>Видно Windows рисует каждый GDI пиксел как 4 физических пиксела — неряшливо.

А что с этим теперь делать будут?
Ну то есть обычный виндовый проводник тоже ж на Windows GDI, и всякие панели управления, стандартные диалоги, вот это вот всё, что на обычных WinAPI Common Controls...

Максим Рогожин:

МР>Я программировать оконные приложения Windows (используя Windows API, а не какие-нибудь фреймворки типа MFC) учился в начале 2000-х и с тех пор не занимался этим) И вот у меня тут вопрос возник — ничего в принципах работы графической системы Windows с тех пор принципиально не поменялось случаем? Ну может там все переходит на .NET и CLR, к примеру, или еще чего? Может быть в связи с унификацией десктопных и мобильных платформ какие-то принципиальные изменения в графическую систему вносятся/будут внесены? Или принципы графической системы Windows (message loop, оконная процедура, GetMessage(), DispatchMessage() и т.д.) остались незыблемы?

Если хочешь, чтобы приложение работало на всех разновидностях винды, и могло распространяться через их магазин (как он там называется?), тогда только UWP.
Там что-то навроде html, а обработчики событий на скриптах или на дотнете (если соврал, знатоки поправят).

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

AG>А что с этим теперь делать будут?
AG>Ну то есть обычный виндовый проводник тоже ж на Windows GDI, и всякие панели управления, стандартные диалоги, вот это вот всё, что на обычных WinAPI Common Controls...
Нормально всё там с GDI. Старые приложения автоматические масштабируются и получается гадость навроде той, что показал c-smile. Новые dpi aware приложения рисуются пиксел в пиксел.

PS: Виртуальные пикселы и неконтроллируемый субпиксельный рендеринг — вот где зло!

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

AG>А что с этим теперь делать будут?
Writing DPI-Aware Desktop and Win32 Applications вообще стоит хотя бы наискость пролистать.

Здравствуйте, Максим Рогожин, Вы писали:

МР>Я программировать оконные приложения Windows (используя Windows API, а не какие-нибудь фреймворки типа MFC) учился в начале 2000-х и с тех пор не занимался этим) И вот у меня тут вопрос возник — ничего в принципах работы графической системы Windows с тех пор принципиально не поменялось случаем? Ну может там все переходит на .NET и CLR, к примеру, или еще чего? Может быть в связи с унификацией десктопных и мобильных платформ какие-то принципиальные изменения в графическую систему вносятся/будут внесены? Или принципы графической системы Windows (message loop, оконная процедура, GetMessage(), DispatchMessage() и т.д.) остались незыблемы?

Принципы-то остались, а вот реализация поменялась. Тут уже многое сказали, я хочу лишь напомнить еще про WPF. Есть в этих приложениях message loop, оконная процедура, GetMessage(), DispatchMessage() и т.д., вот только окон нет. Вернее, есть одно окно, а все остальное нарисовано — windowsless controls. А отсюда всякое масштабирование, которое раньше в диалогах, например, было обычно не принято.

Здравствуйте, Дрободан Фрилич, Вы писали:

ДФ>Если хочешь, чтобы приложение работало на всех разновидностях винды, и могло распространяться через их магазин (как он там называется?), тогда только UWP.
ДФ>Там что-то навроде html, а обработчики событий на скриптах или на дотнете (если соврал, знатоки поправят).

Гм... Начнём по порядку.
1) WPF — краеугольный камень современного Windows UI. Ну как современного — начиная с 2006 года, т.е. больше 10 лет. Идеологически WPF действительно напоминает HTML (стили как в CSS, гриды как основной элемент вёрстки и т.п.)
2) На основе WPF есть ряд Фреймворков, которые позволяют делать UI для десктопа, для телефона, а также universal apps (одновременно для десктопа, телефона и что там ещё).
3) События и их обработчики там есть, конечно, но есть много иных приколюх (типа тех же behaviors, transitions и т.п.).

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

MA>Новые dpi aware приложения рисуются пиксел в пиксел.

На Windows10 C:\Windows\explorer.exe использует Direct2d и DirectWrite.

Дальше — больше.

Дело в том что новые I18N фичи появились только в DirectWrite. Uniscribe так и застыл на версии usp10.dll

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

MD>Здравствуйте, Дрободан Фрилич, Вы писали:

ДФ>>Если хочешь, чтобы приложение работало на всех разновидностях винды, и могло распространяться через их магазин (как он там называется?), тогда только UWP.
ДФ>>Там что-то навроде html, а обработчики событий на скриптах или на дотнете (если соврал, знатоки поправят).

MD>Гм... Начнём по порядку.
MD>1) WPF — краеугольный камень современного Windows UI. Ну как современного — начиная с 2006 года, т.е. больше 10 лет. Идеологически WPF действительно напоминает HTML (стили как в CSS, гриды как основной элемент вёрстки и т.п.)

А ты правильно перевел "краеугольный" по отношению к WPF? Может там было всё же "надгробный"?

Что конкретно написано в современном Windows на WPF?

Из того что знаю достоверно про WPF: из всех антивирусов только Kaspersky использует WPF для UI. Остальные известно что.
Была попытка сделать Evernote UI на WPF (версия 3.5 емнип). disaster получился, срочно переписали на C++ и plain windows API.


Из того что более менее работает на WPF это GitHub Desktop application
Но и то, для того чтобы нарисовать timeline они туда воткнули Chrome: https://githubengineering.com/cross-platform-ui-in-github-desktop/

Архитектура сего приложения вообще вызывает какое-то странное ощущение ...

Написали бы уже его на Electron всё ...

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

CS>Из того что более менее работает на WPF это GitHub Desktop application

Visual Studio 2015 вроде на WPF, не?

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

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

CS>>Из того что более менее работает на WPF это GitHub Desktop application

AG>Visual Studio 2015 вроде на WPF, не?

А фиг его знает, там какие-то child окна с WinForms есть но это конечно ни о чем не говорит.

Но судя по тому что на Microsoft Visual Code (что ни разу не WPF) они столько людей отрядили то Visual Studio 2020 будет не WPF точно.

Что-то мне говорит что MS трудится над Electron с Edge engine внутри.

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

CS>А ты правильно перевел "краеугольный" по отношению к WPF? Может там было всё же "надгробный"?

Ну, каждый может сам выбрать эпитеты, но феншуйный способ рисовать UI для десктопных/мобильных приложений — именно WPF. Просто хардкорному Win32-разработчику тяжко менять парадигму, переходя на windowless controls, поэтому многие шарашат как привыкли (QT, Электрон, MFC, WTL).

CS>Что конкретно написано в современном Windows на WPF?

Тайловый метро-десктоп восьмёрки, меню "Пуск" десятки — выглядят именно как типовой WPF (даже если не являются им технологически).

CS>Была попытка сделать Evernote UI на WPF (версия 3.5 емнип). disaster получился, срочно переписали на C++ и plain windows API.

Не осилили WPF? Хм, могли ж и на WinForms запилить, хотя после появления WPF он считается legacy.
Не осилили .NET в целом? Хм, скорее, сработали какие-то внутренние стратегические цели, поэтому и перешли C++. В общем, дело ясное, что дело тёмное, и WPF тут просто один из предметов декораций.

CS>Из того что более менее работает на WPF это GitHub Desktop application
CS>Но и то, для того чтобы нарисовать timeline они туда воткнули Chrome: https://githubengineering.com/cross-platform-ui-in-github-desktop/
CS>Архитектура сего приложения вообще вызывает какое-то странное ощущение ...
CS>Написали бы уже его на Electron всё ...

Опен-сорс во всей красе — я тебя слепила из того что было. В общем, опять WPF виноват

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

CS>>Что конкретно написано в современном Windows на WPF?

MD>Тайловый метро-десктоп восьмёрки, меню "Пуск" десятки — выглядят именно как типовой WPF (даже если не являются им технологически).

Так "выглядит" или таки "WPF"?

CS>>Была попытка сделать Evernote UI на WPF (версия 3.5 емнип). disaster получился, срочно переписали на C++ и plain windows API.

MD>Не осилили WPF? Хм, могли ж и на WinForms запилить, хотя после появления WPF он считается legacy.
MD>Не осилили .NET в целом? Хм, скорее, сработали какие-то внутренние стратегические цели, поэтому и перешли C++. В общем, дело ясное, что дело тёмное, и WPF тут просто один из предметов декораций.

Причем здесь "не осилили"? Я же тебе говорю что 3.5 версия вышла и работала как-то.

А вот пользователи... те не смогли, да. Приложение утилитарное — должно стартовать в пределах 100ms, занимать мало памяти в background.
Природа таких приложений требует легковесности. Copy-paste note и дальше работаешь.

Здравствуйте, Максим Рогожин, Вы писали:

МР>Еще раз четко сформулирую вопросы:
МР>1) Изменились ли принципы работы графической системы в современных версиях Windows по сравнению с Windows 98, Windows XP?

нет

МР>2) Если не изменились, то в обозримом будущем какие-то изменения предвидятся?

нет, но всех могут принудительно загнать в свой магазин и чего нибудь навязать.

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

CS>В качестве примера:
CS>Вот Evernote с GDI UI и то же в Sciter (использует Direct2D) на high-dpi мониторе:
CS>Видно Windows рисует каждый GDI пиксел как 4 физических пиксела — неряшливо.

плохой пример, просто Evernote не DPI Aware и всё.

для обычного интерфейса просто добавляется манифест и всё становится как в Sciter с обычными виндовыми контролами, а при добавлении битмапов под разные dpi даже лучше.

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

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

CS>>В качестве примера:
CS>>Вот Evernote с GDI UI и то же в Sciter (использует Direct2D) на high-dpi мониторе:
CS>>Видно Windows рисует каждый GDI пиксел как 4 физических пиксела — неряшливо.

U>плохой пример, просто Evernote не DPI Aware и всё.

U>для обычного интерфейса просто добавляется манифест и всё становится как в Sciter с обычными виндовыми контролами, а при добавлении битмапов под разные dpi даже лучше.

Если бы все так просто было бы то никаких проблем бы не было ...
Запусти например Device Manager в Windows 10 на high-dpi monitor — увидишь ту же хрень. Уж в Редмонде могли бы manifest всем exe подсунуть — ан нет ...

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

U>Здравствуйте, Максим Рогожин, Вы писали:

МР>>Еще раз четко сформулирую вопросы:
МР>>1) Изменились ли принципы работы графической системы в современных версиях Windows по сравнению с Windows 98, Windows XP?

U>нет

Ты про WM_DPICHANGED message случаем не забыл? А про OpenType шрифты? Чем ты их рендерить предлагаешь если "нет"?
А про то что GDI alpha канал как не знал ничего так и не знает? Как ты предлагаешь делать что либо близкое к start menu / action center?

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

CS>Если бы все так просто было бы то никаких проблем бы не было ...

их и нет

CS>Запусти например Device Manager в Windows 10 на high-dpi monitor — увидишь ту же хрень. Уж в Редмонде могли бы manifest всем exe подсунуть — ан нет ...

то, что мелкомягкие не могут допилить свою недоось и тянут две панели управления и в некоторых местах вообще иконки от винды 3.11(образно) это их проблемы


Вынь10 300%
дефолтный проект из студии на обычных виндовых контролах, только включил DPI Aware, ещё сунуть нормальную иконку и всё.

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

МР>>>Еще раз четко сформулирую вопросы:
МР>>>1) Изменились ли принципы работы графической системы в современных версиях Windows по сравнению с Windows 98, Windows XP?

U>>нет

CS>Ты про WM_DPICHANGED message случаем не забыл? А про OpenType шрифты? Чем ты их рендерить предлагаешь если "нет"?
CS>А про то что GDI alpha канал как не знал ничего так и не знает? Как ты предлагаешь делать что либо близкое к start menu / action center?

"рюшечки" как рисовались всякими костылями, так и рисуются, ничего не изменилось

WM_DPICHANGED это отдельная тема, в большинстве случаев не нужная, клинических случаев использования мониторов с разными настройками dpi я думаю можно насчитать по пальцам.

а теперь смотрим на картинку в моём другом сообщении и отвечаем на вопрос топикстартера в начале этого сообщения.

Здравствуйте, c-smile,

Mr.Delphist, видимо, неправильно выразился: нужно было сказать не WPF, а XAML. WPF, UWP, Silverlight, Xamarin — XAML-фреймворки.

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

U>WM_DPICHANGED это отдельная тема, в большинстве случаев не нужная, клинических случаев использования мониторов с разными настройками dpi я думаю можно насчитать по пальцам.
ЩИТО?

Самый тупой случай — ноутбук с HiDPI и десктопный монитор с обычным DPI, но большим размером. Окно перетаскивают с одного монитора на другой. Всё.

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

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

На кнопку в about box глянь. Там бордюры в три раза тоньше того что нужно.

Даже вот такое простое действо вызывает проблемы.

Т.е. если все делать на коленке то сойдет.

Например вот флагман векторной графики так сказать:



Это я еще настройки подкрутил. Ибо в настройках по умолчанию работать невозможно.

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

_>Здравствуйте, c-smile,

_>Mr.Delphist, видимо, неправильно выразился: нужно было сказать не WPF, а XAML. WPF, UWP, Silverlight, Xamarin — XAML-фреймворки.

XAML как и HTML это markup languages.

Какое отношение это имеет к вопросу "Изменились ли принципы работы графической системы в современных версиях Windows по сравнению с Windows 98, Windows XP?" ?

Или имеется ввиду ответ типа "Забей, пиши UI в HTML"? Ну дык я лично согласен.

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

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

МР>>>>Еще раз четко сформулирую вопросы:
МР>>>>1) Изменились ли принципы работы графической системы в современных версиях Windows по сравнению с Windows 98, Windows XP?

U>U>>нет

CS>>Ты про WM_DPICHANGED message случаем не забыл? А про OpenType шрифты? Чем ты их рендерить предлагаешь если "нет"?
CS>>А про то что GDI alpha канал как не знал ничего так и не знает? Как ты предлагаешь делать что либо близкое к start menu / action center?

U>"рюшечки" как рисовались всякими костылями, так и рисуются, ничего не изменилось

300dpi — это в девять раз больше пикселей на экране по сравнению с 96dpi.

У тебя производительность процессора выросла в 9 раз? За для нарисовать "рюшечки" на том экране?

В GDI фактически только одна hardware accelerated функция.

BitBlt называется.

Много ты ей нарисуешь? Скажем что-то типа масштабируемого SVG с antialiased primitives и всё такое...

U>WM_DPICHANGED это отдельная тема, в большинстве случаев не нужная, клинических случаев использования мониторов с разными настройками dpi я думаю можно насчитать по пальцам.

U>а теперь смотрим на картинку в моём другом сообщении и отвечаем на вопрос топикстартера в начале этого сообщения.

Ты вообще современной UI разработкой занимался ли? А notebook современный видел?
Такое впечатление что "нет" в обоих случаях.

МР>1) Изменились ли принципы работы графической системы в современных версиях Windows по сравнению с Windows 98, Windows XP?
Разучились попадать в пикселы (чёрные буквы на белом фоне расплываются на +-3 пиксела радужным разблуриванием).
Разучились отображать иконки из >2 цветов одновременно.
МР>2) Если не изменились, то в обозримом будущем какие-то изменения предвидятся?
Windows11-приложения будут чёрными квадратами Малевича с 5 дрыгающимися рекламными баннерами, за 99.9$

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

CS>На кнопку в about box глянь. Там бордюры в три раза тоньше того что нужно.

кому нужно?
это стандартный виндовый пушбаттон, как он выглядит решает винда в зависимости от версии винды и настроек dpi.

CS>Даже вот такое простое действо вызывает проблемы.

у кого?

CS>Например вот флагман векторной графики так сказать:
CS>Это я еще настройки подкрутил. Ибо в настройках по умолчанию работать невозможно.

что это, зачем это, и какое это отношение имеет к принципам работы графической системы ?

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

U>>WM_DPICHANGED это отдельная тема, в большинстве случаев не нужная, клинических случаев использования мониторов с разными настройками dpi я думаю можно насчитать по пальцам.
C>ЩИТО?

C>Самый тупой случай — ноутбук с HiDPI и десктопный монитор с обычным DPI, но большим размером. Окно перетаскивают с одного монитора на другой. Всё.

хммм, на самом деле интересная тема, странно что до сих пор никто из клиентов на это не пожаловался...

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

CS>300dpi — это в девять раз больше пикселей на экране по сравнению с 96dpi.
CS>У тебя производительность процессора выросла в 9 раз? За для нарисовать "рюшечки" на том экране?

производительность процессора ... dpi

CS>В GDI фактически только одна hardware accelerated функция.
CS>BitBlt называется.
CS>Много ты ей нарисуешь? Скажем что-то типа масштабируемого SVG с antialiased primitives и всё такое...

для начала вопрос, а оно мне и ТС надо?
если бы ТС интресовали WPF, XAML, QT, итд, то он бы наверное конкретно про них спросил, а не про "Принципы работы графической системы Windows" которые не поменялись ни на грамм, вообще, и будут жить ещё долго, наверное дольше ваших любимых костылей которые приходят и уходят.

U>>а теперь смотрим на картинку в моём другом сообщении и отвечаем на вопрос топикстартера в начале этого сообщения.
CS>Ты вообще современной UI разработкой занимался ли? А notebook современный видел?


ещё раз читаем первое сообщение тописктартера и не тупим,
GetMessage(), DispatchMessage() это не про "рюшечки".

CS>Такое впечатление что "нет" в обоих случаях.

да, костыли меня не интересуют, я пилю интерфейс на голых виндовых контролах, с dpi aware, работает нормально налюбом хламе и при при любом масштабе, ЧЯДНТ?

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

U>если бы ТС интресовали WPF, XAML, QT, итд, то он бы наверное конкретно про них спросил, а не про "Принципы работы графической системы Windows" которые не поменялись ни на грамм, вообще, и будут жить ещё долго, наверное дольше ваших любимых костылей которые приходят и уходят.
Вообще-то, поменялись. Direct*-вещи работают не через GDI.

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

U>я пилю интерфейс на голых виндовых контролах, с dpi aware, работает нормально налюбом хламе и при при любом масштабе

Справедливости ради нужно отметить, что реально нормально будет только начиная с Creators Update, в котором появится DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2.

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

CS>В GDI фактически только одна hardware accelerated функция.

CS>BitBlt называется.

CS>Много ты ей нарисуешь? Скажем что-то типа масштабируемого SVG с antialiased primitives и всё такое...

Всё верно, но современный GDI зачастую актуален лишь для работы с окном как контейнером, блиттинг ему нужен лишь при перетаскивании за шапку тудым-сюдым. Внутренности окна и их рендеринг — это уже windowless-контролы, которые в том же WPF могут рисоваться через GPU acceleration (а значит, с антиалиасингом и всем таким). Как-то так.

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

CS>Что-то мне говорит что MS трудится над Electron с Edge engine внутри.
И тем не менее — текущий веб — просто импотент для представления "нормальных" интерфейсов.
Т.е. веб на самом деле универсальнее всех на сегодня (проще но и нехилые недостатки есть). Не хватает иметь расширений навроде твоих.
Но имхо — нихера подобного в стандарте не будет. Флексы толком не вошли в жизнь, а всё равно ущербные они как ни крути. Увы.

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

Без возможности привязки (snap) к device pixels — за виртуальные нужно отрывать ноги с руками и ногами. Тут вы господа афаик все едины. Разве что в твоём sciter можно сказать snap borders to pixels. Можно?

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

CS>>Что-то мне говорит что MS трудится над Electron с Edge engine внутри.
MA> И тем не менее — текущий веб — просто импотент для представления "нормальных" интерфейсов.
MA> Т.е. веб на самом деле универсальнее всех на сегодня
Тоже мне открытие, это было известно ещё до QT с его qml.

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

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

MA>Без возможности привязки (snap) к device pixels — за виртуальные нужно отрывать ноги с руками и ногами. Тут вы господа афаик все едины. Разве что в твоём sciter можно сказать snap borders to pixels. Можно?

В Sciter px и dip это разные length units.

px это физический пиксел т.е. border:1px solid; будет именно 1 пиксел на данном физическом экране.

Тогда как border:1dip solid; будет 1 пиксел на 96dpi мониторе и 2 пиксела на 200dpi мониторе.

Т.е. 1dip это логический device independent pixel == 1/96in.

В web 1px это то что в sciter 1dip. Т.е. в browsers и Atom/Electron соответственно невозможно нарисовать линию в строго один физический пиксел.
Т.е. на web платформе нет физических length units, только logical ones: 1px = 1/96in, 1pt = 1/72in, etc.

Почему так — науке не известно.

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

PTC Mathcad — полностью сделан на WPF. Работает шустро.

Я думаю что большого количества приложений , доступных для покупки простым людям, сделанных не то что на WPF, а просто на .Net не так много. Другое дело всякие корпоративные приложения, о которых мы ничего не знаем.

А когда я читаю о том, что интерфейсу _антивируса_ нужно аппаратное ускорение для от рисовки, мне становится немного стремно.

Ты на самом деле не до оцениваешь шустрость GDI, который начинал свое существование в Windows 1.0 на 8086 процессоре и 128 килобайтах памяти. И уже тогда он прекрасно справлялся с рисованием всего, что нужно. А уж на 386/486 процессорах с парой мегабайт памяти через него прекрасно рисовали все что нужно всякие Автокады (они, правда и в ДОС с рисованием проблем не испытывали), Ворды, Эксели, Визио и куча прочего софта. GDI+ отлично справлялся с рисованием красивостей интерфейса в Windows XP. Ну и т.д.

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

A>Ты на самом деле не до оцениваешь шустрость GDI, который начинал свое существование в Windows 1.0 на 8086 процессоре и 128 килобайтах памяти. И уже тогда он прекрасно справлялся с рисованием всего, что нужно. А уж на 386/486 процессорах с парой мегабайт памяти через него прекрасно рисовали все что нужно всякие Автокады (они, правда и в ДОС с рисованием проблем не испытывали), Ворды, Эксели, Визио и куча прочего софта. GDI+ отлично справлялся с рисованием красивостей интерфейса в Windows XP. Ну и т.д.

GDI это CPU drawing. Без antialiasing и без альфаканала. На экране в 800*600 или 1024*768 пикселей проблем не было если не нужно было antialiasing и альфаканал. Т.е. W10 start menu GDI нарисовать уже не сможет в принципе.
Но и то для того чтобы рисовать видео например GDI не справлялся — требовалось DirectDraw — т.е. запись напрямую в видео память минуя этот самый GDI.

Средний high-DPI монитор это 3840*2160 — т.е. количеств пикселей в 200 раз выросло.
Современные же процессоры недалеко ушли от тех на которых работала XP — раза в два/три быстрее.
Понятно что рисовать чисто CPU уже нельзя.

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

MA>>Без возможности привязки (snap) к device pixels — за виртуальные нужно отрывать ноги с руками и ногами. Тут вы господа афаик все едины. Разве что в твоём sciter можно сказать snap borders to pixels. Можно?
CS>В Sciter px и dip это разные length units.
Да-да, я знаю что у тебя по взрослому. Но я говорил немножечко о другом: вот у нас допустим в тексте встречается inline-block и мы хотим что-бы весь блок был привязан к пикселам (т.е. что бы однопиксельные бордюры не размывались). Ну или даже 1dip бордюры которые пусть будут 1.5px, но хотим что-бы left-top и right-bottom были привязаны к пикселам, а не так как получится в зависимости от того куда попал блок и его ширины (опять таки жестко не заданной). Ну или классическая таблица — что-бы разделители колонок не "плыли" от звёзд. Т.е. безусловно то, что есть разные lenght unit — это правильно. Но в непредсказуемом flow именно нужны какие-то хитрые привязки / позиционирования.

В общем-то я больше даже сетую на отсутствие вменяемых механизмов сделать две линии одинаковыми.

А в вебе px — это dip, имхо, только потому, что умные дяди посчитали, что они умнее всех. Их наверное понять можно, но с трудом.