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

_>а в той же Qt уже просто одной функцией http://doc.qt.io/qt-5/qtwin.html#enableBlurBehindWindow

DWM не работает в новых виндах.
Я одно время с ним серьёзно играл, кароч, оно "работает", т.е. никаких ошибок при инициализации и установке (довольно-таки нетривиальной!) св-в не выдаёт, т.е. все результаты соответствуют тому, что композиция якобы включена.

Но DwmDefWindowProc ничего не делает, то бишь, всегда возвращает FALSE, т.е. отрисовка NC-областей выполняется через стандартную DefWindowProc.

В двух словах, процедура окна, использующего DWM, выглядит так:

...
{
    LRESULT dwmResult;

    if(DwmDefWindowProc(hwnd, msg, wParam, lParam, &dwmResult))
        return dwmResult;
}
...
switch(msg) 
{
...
default:
    return DefWindowProc(hwnd, msg, wParam, lParam);
}

_>Это разве не тоже самое или там какой-то особенный blur? )))

Разница в том, что раньше его не надо было рисовать самому ручками.
Если даже была потребность растянуть этот блур и на клиентскую область окна, то это указывалось через однократный вызов DwmExtendFrameIntoClientArea(hwnd, margins).

То бишь, DWM скрывал от юзверя низлежащий DirectX, бо обращение с низкоуровневой графикой всегда многословное, там несколько видов поверхностей, пайплайн местами не прост, форматов RGB дохрена и т.д. до бесконечности, т.е. в этой низкоуровневой механике легко допустить массу ошибок. Например, можно было подменить отображаемую поверхность экрану и выйти из приложения, забыв вернуть дефлотную и усё, только перезагрузка, бо все приложения пишут в активную поверхность, а та не установлена как отображаемая. Теперь винды чуть "поумнели", всё прекрасно вернут взад, то бишь изоляция стала получше.

Теперь можете развлекаться в DX, а там не только несчастный блур, а вообще что душе угодно. ))

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

CS>>Принципиально разница в дизайне состоит в том что [очень условно] Windows отказывается от themes.
S>Это просто жуть!!!

Дык, начиная с XP темы были для common controls и GDI, а приложения магазина не используют commctrl.dll.

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

CS>>В Windows 7 это всё вообще очень сложно сделать — child окна там непрозрачные, ClearType который с альфаканалом не дружит в принципе и всё такое.
DR>Погодите, так что с ClearType?

Не актуален для высокого DPI.
А вообще, волноваться не о чем.
Десктопные приложения будут поддерживаться еще бесконечно долго, а в них с ClearType всё ОК.

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

МД>>Ты наверное будешь удивлен, но по скорости GDI до сих лучше всех для нативных приложений. И проще.
CS>GDI это CPU rendering примитивов.

Опять старая песня. ))
Уже ведь разбирали, что GDI-драйвера даже образы шрифта кешируют в памяти картейки.

С темами, начиная от WinXP, та же фигня, бо тема — это набор битмапов, а те хранятся в картейке, пока в ней хватает памяти.
Причём, одни и те же экземпляры битмапов переиспользуются м/у приложениями.

А в приложениях UWP не переиспользуется ни че го.
Прожорливые они даже в минимальном варианте.


CS>По определению быстро не может. Особенно на high-DPI мониторах.

Быстро-то может, какие проблемы?
Там неудобство поджидало с другой стороны — это растяжка битмапов.
В общем случае выглядит так себе.

Поэтому на high-DPI мониторах надо рисовать уже вектором.
И это тормознее, справедливости ради, чем растягивать битмап, который уже сидел до этого в картейке.

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

SP>Я был бы очень удивлен, если б мне кто-то хотя бы теоретически мог объяснить, как ГДИ может быть быстрее ДиректИкса.

Смотря в каких сценариях.
Например, высококачественный текст GDI рисует быстрее, бо в нём прямо в драйвере живёт довольно-таки сложный кеш битмапов-символов.

2D операции в GDI тоже очень шустрые, если не надо менять перед каждой операцией перо-кисть.
Работает в точности на уровне DirectX по скорости, когда тот рисует прямо в экранную поверхность.

А когда оба рисуют в скрытую поверхность, то оба рисуют намного быстрее и опять же примерно с одинаковой скоростью.
Почему double buffering и популярен в GDI — это банально быстрее.

А так-то оба, что DirectX, что GDI — это юзер-левельные обертки над низкоуровневым драйвером одной и той же картейки.
И с какой радости одна и та же картейка должна выдавать разную производительность при заливке, скажем, GDI GradientFill в аналогичной операции над коллекцией вершин в DX?
Там происходящее в точности идентично, разве что в случае Direct 3D надо было гнать на картейку больше данных, бо каждая вершина описывается в 3-хмерном пространстве, т.е. тупо z=0. И этот глупый 0 постоянно туда-сюда гонялся, пока не выпустили Direct2D в 2012-м году.

Ну и, дрова GDI еще с начала 2000-х были уже очень неплохи.
Лучших не существовало в природе.

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

O>а еще можно както так https://msdn.microsoft.com/en-us/library/windows/desktop/aa969537(v=vs.85).aspx#blurbehind

В 10-ке не работает.

O>>а еще можно както так https://msdn.microsoft.com/en-us/library/windows/desktop/aa969537(v=vs.85).aspx#blurbehind
V>В 10-ке не работает.
и почему меня это не удивляет..

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

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

CS>>В Windows 7 это всё вообще очень сложно сделать — child окна там непрозрачные, ClearType который с альфаканалом не дружит в принципе и всё такое.

DR>Погодите, так что с ClearType?


По определению ClearType это механизм отрисовки текста на непрозрачном background с суперсамплингом.

Т.е. нельзя отрисовать текст на прозрачный bitmap (window surface bitmap) и потом уже blend этого bitmap на экран. Не работает так в принципе [с ClearType].

Вот например в Windows 7 под caption text приходится подкладывать непрозрачный фон таким вот извращенным способом:


Это не от хорошей жизни, а из-за clear type.

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

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

_>>а в той же Qt уже просто одной функцией http://doc.qt.io/qt-5/qtwin.html#enableBlurBehindWindow

V>DWM не работает в новых виндах.

Ну не выдумывай. Windows 10 это DWM и только DWM. В Windows 7 DWM можно было отключать (Basic Window Theme), в 10-ке DWM неотключаема.

_>>Это разве не тоже самое или там какой-то особенный blur? )))

Windows 7 blur делается с kernel 3-4 пиксела.
Windows 10 и MacOS blur это filter kernel 20-30 пиксела.

Вычислительная сложность Gaussian blur — O(M*N) где M размер kernel, а N количество пикселов экрана.

Т.е. W7 еще можно было технически делать blur с пом. CPU то в W10 уже нет — нужен GPU для работы.

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

V>Не актуален для высокого DPI.

В Edge и остальных WPF приложениях заметно размытый текст даже на 27" 4K мониторе (160 dpi). У подавляющего большинства мониторов DPI ниже.

V>Десктопные приложения будут поддерживаться еще бесконечно долго, а в них с ClearType всё ОК.

Насколько я понимаю, они хотят использовать этот стиль по всей операционной системе, а не только в своём магазине.

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

V>>DWM не работает в новых виндах.
CS>Ну не выдумывай. Windows 10 это DWM и только DWM.

От всей богатой функциональности DWM там осталась только композиция окон.
Я же написал следом:

DwmDefWindowProc ничего не делает, то бишь, всегда возвращает FALSE

CS>Вычислительная сложность Gaussian blur — O(M*N) где M размер kernel, а N количество пикселов экрана.

Не уверен, что нужен Gaussian blur на весь экран.
Можно ограничиться обычным линейным размытием с конечным радиусом.
При такой сильной степени размытия это однофигственно.

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

V>>Не актуален для высокого DPI.
DR>В Edge и остальных WPF приложениях заметно размытый текст даже на 27" 4K мониторе (160 dpi). У подавляющего большинства мониторов DPI ниже.

Возьми 4к на 22" и будет тебе счастье.


V>>Десктопные приложения будут поддерживаться еще бесконечно долго, а в них с ClearType всё ОК.
DR>Насколько я понимаю, они хотят использовать этот стиль по всей операционной системе, а не только в своём магазине.

Что значит "во всей операционной системе"?
В ГУИ конфигурации/сеттингов?
Туда лазят один-два раза при первоначальной установке.
Целевые приложухи всё-равно классические десктопные — ради которых ты комп включаешь, собсно.

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

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

V>>>DWM не работает в новых виндах.
CS>>Ну не выдумывай. Windows 10 это DWM и только DWM.

V>От всей богатой функциональности DWM там осталась только композиция окон.
V>Я же написал следом:
V>

V>DwmDefWindowProc ничего не делает, то бишь, всегда возвращает FALSE

Всё что нужно она делает если окно сконфигурировано так что ей нужно работать. WM_NCPAINT, WM_NCHITTEST и WM_DWM*** сообщения.

CS>>Вычислительная сложность Gaussian blur — O(M*N) где M размер kernel, а N количество пикселов экрана.

V>Не уверен, что нужен Gaussian blur на весь экран.
V>Можно ограничиться обычным линейным размытием с конечным радиусом.
V>При такой сильной степени размытия это однофигственно.

На весь экран это worst case. А если у тебя K окон с размытием друг на друге то еще и O(M*N*K) — т.е. весь Z-order стек размывать приходится.

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

V>>DwmDefWindowProc ничего не делает, то бишь, всегда возвращает FALSE
CS>Всё что нужно она делает если окно сконфигурировано так что ей нужно работать. WM_NCPAINT, WM_NCHITTEST и WM_DWM*** сообщения.

Ну ты попробуй.


V>>Не уверен, что нужен Gaussian blur на весь экран.
V>>Можно ограничиться обычным линейным размытием с конечным радиусом.
V>>При такой сильной степени размытия это однофигственно.

CS>На весь экран это worst case. А если у тебя K окон с размытием друг на друге то еще и O(M*N*K) — т.е. весь Z-order стек размывать приходится.

Не приходится. Это же композитор, т.е. он оперирует статическими картинками, а не рисует по требованию.
Т.е. низлежащие картинки сгенерили свой рисунок ну и всё. При перемещении окна верхнего уровня надо обсчитывать только его.

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

CS>По определению ClearType это механизм отрисовки текста на непрозрачном background с суперсамплингом.
CS>Т.е. нельзя отрисовать текст на прозрачный bitmap (window surface bitmap) и потом уже blend этого bitmap на экран. Не работает так в принципе [с ClearType].

Теоретически это можно, например сугубо рисовать символы ручками. ))

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

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

V>>Не актуален для высокого DPI.

ClearType используется и в high-dpi, можно посмотреть в Edge или вот на 192ppi экране:



DR>В Edge и остальных WPF приложениях заметно размытый текст даже на 27" 4K мониторе (160 dpi). У подавляющего большинства мониторов DPI ниже.

Edge к WPF не имеет никакого отношения. Edge это UWP приложение (но похоже что они начали его мигрировать из-под UWP).
У WPF свой независимый rendering stack и, да, WPF славится размытием текста.

V>>Десктопные приложения будут поддерживаться еще бесконечно долго, а в них с ClearType всё ОК.

DR>Насколько я понимаю, они хотят использовать этот стиль по всей операционной системе, а не только в своём магазине.

Административные утилиты так и останутся я думаю.

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

DR>>В Edge и остальных WPF приложениях заметно размытый текст даже на 27" 4K мониторе (160 dpi). У подавляющего большинства мониторов DPI ниже.

CS>Edge к WPF не имеет никакого отношения. Edge это UWP приложение (но похоже что они начали его мигрировать из-под UWP).
CS>У WPF свой независимый rendering stack и, да, WPF славится размытием текста.

Да, спасибо, я имел в виду именно UWP. 😳

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

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

V>>>DwmDefWindowProc ничего не делает, то бишь, всегда возвращает FALSE
CS>>Всё что нужно она делает если окно сконфигурировано так что ей нужно работать. WM_NCPAINT, WM_NCHITTEST и WM_DWM*** сообщения.

V>Ну ты попробуй.

А чего мне пробовать? Она у меня вызывается и работает там где надо (на окнах с DwmExtendFrameIntoClientArea например).

V>>>Не уверен, что нужен Gaussian blur на весь экран.
V>>>Можно ограничиться обычным линейным размытием с конечным радиусом.
V>>>При такой сильной степени размытия это однофигственно.

CS>>На весь экран это worst case. А если у тебя K окон с размытием друг на друге то еще и O(M*N*K) — т.е. весь Z-order стек размывать приходится.

V>Не приходится. Это же композитор, т.е. он оперирует статическими картинками, а не рисует по требованию.
V>Т.е. низлежащие картинки сгенерили свой рисунок ну и всё. При перемещении окна верхнего уровня надо обсчитывать только его.

Если бы всё так просто было ... Запусти видео а поверх него calculator.exe какой-нить в 10-ке — всё увидишь.
А если несколько UWP окон то увидишь как весь стек размывается друг под другом.

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

CS>Вот для того чтобы сделать такое окно
CS>[url=https://sciter.com/wp-content/uploads/2018/06/acrylic3-960x650.png]Image: acrylic3-960x650.png
CS>[/url]
CS>ему нужно выставить флаг WS_EX_NOREDIRECTIONBITMAP и рисовать содержимое непосредственно в DirectComposition visual tree десктопа — т.е. напрямую DirectX surface экрана.
CS>Эра GDI прошла.

Вот я бы убивал бы программеров, которые такой GUI делают.
Ну или по крайней мере кое-какие места бы им отрывал, чтобы не плодились.

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

CS>Вот для того чтобы сделать такое окно
CS>https://sciter.com

Спасибо за ссылку на рассадник ЗЛА и ГОВНА!