Зачем DPI aware портит нам жизнь?
Вот кстати не пойму, накой надо было уменьшать пикселы, неужели кому-то они казались слишком большими?
Интересно, они уже починили отот баг, когда ты через SetCursorPos ставишь курсор в одно место (в центр), а он из-за всех этих dpi преобразований оказывается в другом (плюс/минус один пиксель), из-за чего игры, в которых мышь обрабатывается через Set(Get)CursorPos, сломалось (камера начинает крутиться).
nes
> Вот кстати не пойму, накой надо было уменьшать пикселы, неужели кому-то они
> казались слишком большими?
а) они были слишком большие.
б) как бы никогда у пикселя небыло прям вот чёткого размера на всех мониторах, просто раньше разница в десктоп сегменте была не в разы.
>б) как бы никогда у пикселя небыло прям вот чёткого размера на всех мониторах, просто раньше разница в десктоп сегменте была не в разы.
Вроде как он был примерно одинаковым на всех старых мониторах и равнялся примерно 96 pixels / inch.
nes
> Вроде как он был примерно одинаковым на всех старых мониторах и равнялся
> примерно 96 pixels / inch.
или 72 пикселя/дюйм? 🙂
ну ты сам должен понимать что 1024х768 на 14 дюймах и на 17 дюймах это разные вещи. Это конечно не фуллхд или 4к на 24 дюймах, но всё равно разница была и была ощутима.
SuperInoy
Ну вот мне на работе выдали 24 дюймовый монитор с разрешением 3840×2160,
но на нем не реально работать, если не поставить скейлинг 150% (который как не удивительно является рекомендуемой настройкой в системе).
Ну вот на кой хрен мне столько пикселов тут?
nes
> Ну вот на кой хрен мне столько пикселов тут?
чтобы в пейнте на линии в 1 пиксель не видеть лесенку.
nes
> Ну вот мне на работе выдали 24 дюймовый монитор с разрешением 3840×2160,
Объясни им что тебе неудобно, фуллхд моник за 8к тебе вероятно вместо него выдадут 🙂
122
Галочка не спасет ровно никак.
Поставь ее, запусти приложение, затем поменяй в системе DPI скейлинг,
окно измет размер.
122
Короче работает павильно, если вызвать функцию:
nes
> Кто-то свыше решил, что теперь разработчик должен программировать гуйню в
> дюймах и переводить в пикселы (которыми оперируют функции системного апи)
> вручную.
В общем-то не кто-то свыше, а просто внедрили типографские стандарты в отображение текстовой информации на компьютерной технике. Просто у Windows, изначально не всё было хорошо с этим делом и старые нехорошие API до сих пор не выпилили. А вот MacOS X изначально пилилась под типографские стандарты и там нет таких проблем (но это не точно).
nes
> Короче работает павильно, если вызвать функцию:
>
> SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE);
> А это чудо доступно только в windows 10.
А в вин ниже 10 делай пиксель пёрфект без масштабирования. Ибо нефиг сидеть на говне мамонта и при этом покупать 8к мониторы.
SuperInoy
Некоторые утверждают, что семерка лучше десятки, но это уже отдельная тема для холивара.
nes
> Некоторые утверждают, что семерка лучше десятки, но это уже отдельная тема для
> холивара.
Ну я так утверждаю, но накатывать 7-ку на свежее железо всё равно не вижу смысла. А на не свежем будет фуллхд/2к с соответствующей диагональю(за исключением некоторых ноутов с хайдпи экранами)
Высокие значения DPI в ОС Windows
Windows, начиная с Vista, предоставляет два механизма для адаптации приложений к мониторам с высокой плотностью пикселей (точек на дюйм, DPI): увеличенные системные шрифты и полномасштабное увеличение окон. К сожалению, попытка заставить некоторые ваши приложения работать в каком либо из режимов может оказаться безуспешной, благодаря сочетанию нерадивых разработчиков и плохих решений принятых Microsoft.
От переводчика
Методы масштабирования
Чтобы исправить ситуацию, Microsoft решила, что неплохо встроить какой-нибудь метод масштабирование в Windows. Один из двух методов описанных ниже (Windows XP или Vista), применяется когда пользователь устанавливает DPI со значением выше чем стандартные 96 точек на дюйм. Оба метода пытаются увеличить размер элементов изображения.
Масштабирование в стиле Windows XP
Первый из этих методов, как можно догадаться, появился в Windows XP. Этот метод, на самом деле, не является методом масштабирования приложений с графическим интерфейсом как таковой. Масштабируются, при более высоких настройках DPI, только системные шрифты и некоторые элементы пользовательского интерфейса системы (я бы назвал его «метод НЕ масштабирования» в стиле Windows XP).
Все остальные элементы приложений по-прежнему отображаются в масштабе 1:1. Единственной разницей в их внешнем виде является то, что любой текст и некоторые элементы GUI, выводимые с помощью системных функций, вдруг становиться больше. Например, текст на кнопках. Это вызывает очевидные проблемы которые мы обсудим чуть позже.
Масштабирование в стиле Windows Vista или DPI виртуализация
Windows Vista представила второй вариант со странным названием, «масштабирование дисплея», без каких-либо уточнений, видимо, чтобы окончательно запутать пользователей. Мы будем использовать более описательное имя – метод DPI виртуализации. Когда этот метод включен, Windows по-прежнему выполняет масштабирование в стиле Windows XP. Также как и прежде размеры всех системных шрифтов и некоторых элементов интерфейса системы увеличиваются.
Разница в том, что приложения, которые могут правильно использовать высокие значения DPI, должны сообщить об этом Windows. Такие приложения должны установить новый DPI-Aware флаг, либо путем вызова функции Win32 API «SetProcessDPIAware», или, предпочтительно, путем встраивания манифеста с флагом dpiAware. А вот если у приложения отсутствует DPI-Aware флаг, Windows ведет себя по другому, сначала она формирует внутреннее отображение в масштабе 96 точек на дюйм (эмулируя для приложения DPI равный 96), а затем, масштабирует полученное изображение в соответствие с текущими настройками DPI перед выводом на экран.
Это было бы фантастическим метод масштабирования если бы все наши мониторы имели плотность пикселей последних аппаратов iPhones (326 точек на дюйм). К сожалению это не так. Окна приложений масштабированные таким образом выглядят чересчур размыто, при популярном разрешении 120 точек на дюйм (@homm это не разрешение, кстати). Поэтому, Microsoft по умолчанию отключает DPI виртуализацию, если вы выберете плотность пикселей меньше или равную 120 DPI.
Как изменить установки DPI
В Windows 7/8, откройте «Панель управления», a затем выберите «Оформление и персонализация», затем «Экран», и, наконец, выберите «Установить размер шрифта (DPI)» (Windows 7) или «Пользовательские параметры размера» (Windows 8). Вы увидите следующее диалоговое окно (Windows 7, в Windows 8 почти идентично): 
В раскрывающимся списке можно выбрать нужную настройку DPI в процентном соотношении, где 100% соответствует 96 DPI, 125% — как на скриншоте, соответствует 120 точкам на дюйм (можно более точно записать значение вручную). До Windows 8 фактическое значение DPI («пикселей на дюйм») отображалось рядом с размером системного шрифта. Windows 8, по непонятным причинам, не показывает значение DPI, так что вы должны рассчитать его самостоятельно.
Также вы можете приложить линейку (у которой есть шкала в дюймах) к экрану, и пытаться совместить маркировку на ней с маркировкой на экране, изменяя значение в раскрывающимся списке. Флажок, обведенный красным внизу, определяет, следует ли использовать только масштабирование в стиле Windows XP, или также новый способ DPI виртуализации. Если флажок не отмечен, как на скриншоте, то DPI виртуализация включена.
Декламация. Это диалоговое окно пример интерфейса не дружественного к пользователю. На первый взгляд кажется, что это флажок для отключения масштабирования в стиле Windows XP. Но этот метод масштабирования (который только увеличивает системные шрифты и другие элементы пользовательского интерфейса системы — масштабирование Windows XP) всегда включается при выборе высокого значения DPI. На самом деле этот флажок управляет, будет ли этот метод единственным (Использовать только масштабы в стиле Windows XP), или также будет применен метод «DPI виртуализации» для приложений, которые не имеют DPI-Aware флага. Так что этот флажок не контролирует метод масштабирования указанный в его название, а контролирует другой метод масштабирования, нигде не упомянутый — и позволяет использовать новый метод, когда флажок снят!
Ошибка в Windows 8. В дополнение к этому, в Windows 8 это диалоговое окно с ошибкой. Как правило, все работает как и в Windows 7, но состояние флажка не сохраняется на значениях DPI 150% и выше. Когда вы устанавливаете этот флажок, «DPI виртуализация» правильно отключается. Тем не менее, сам флажок остается не отмеченным, когда вы в следующий раз открываете этот диалог.
Изменения в Windows 8.1, или почему все размыто?
В Windows 8.1 флажок для масштабирования в стиле Windows XP исчез, и теперь «DPI виртуализация» никогда, не используется при значениях DPI до 120 включительно, но всегда используется при более высоких значениях для тех программ, у которых отсутствует DPI-Aware флаг. Если некоторые приложения кажутся вам нечеткими, необходимо вручную отключить для них DPI виртуализацию.
Windows 8.1 позволяет использовать несколько мониторов с разным значением DPI. Однако эта функция, также заставляет использовать «DPI виртуализацию» для традиционных приложений, которые перемещаются между мониторами с разными значениями DPI. Чтобы этого избежать, можно отключить в настройках «DPI масштабирование», используя новую опцию «Я хочу выбрать один масштаб для всех дисплеев».
Также Windows 8.1 добавляет специальный переключатель для настройки 200% и новый API, чтобы разработчики могли выборочно отключать «DPI виртуализацию».
Помогите, мои системные шрифты не правильного размера!
Иногда, после изменения настроек DPI, вы можете заметить что некоторые системные шрифты стали слишком большими или слишком маленькими для новых установок. Вероятной причиной является то, что вы используете пользовательскую тему рабочего стола на основе ваших старых настроек DPI. Windows не масштабирует шрифты пользовательской темы.
Если вы на самом деле создали пользовательскую тему рабочего стола и хотите сохранить её, вам придется самостоятельно адаптировать шрифты к новым настройкам DPI. Однако, Windows имеет раздражающую привычку «услужливо» создавать пользовательские темы без вашего ведома, по какой-либо причине. Так что, если вы никогда не создавали пользовательскую тему рабочего стола просто удалите её и вернитесь к стандартной теме.
В Windows 7/8, откройте Панель управления, выберите «Оформление и персонализация», а затем «Персонализация». Если вы видите выбранную запись в строке «Мои темы», это означает, что ОС Windows использует тему пользователя, системные шрифты которой Windows не будет масштабировать. Выберите стандартную тему, например, первую запись в разделе «Темы Aero» (Windows 7) или «Windows» «Темы по умолчанию» (Windows 8) и удалите нежелательные записи в разделе «Мои темы». Теперь, все системные шрифты должны отображаться правильно.
Типы приложений, как они масштабируются (или не масштабируются)
Теперь давайте рассмотрим какие методы должны использоваться для существующих Windows приложений при высоких значениях DPI. Следующая таблица обобщающая, позже мы рассмотрим различные случаи более подробно.
| DPI-Aware флаг не установлен | DPI-Aware флаг установлен | |
| Не DPI-Aware | Нужно использовать DPI виртуализацию | Нужны исправления от разработчиков |
| DPI-Aware | Нужно использовать масштабирование в стиле Windows XP | Всегда масштабируется правильно |
Приложения вообще не заботящиеся о DPI — это либо очень старые или плохо написанные, но, тем не менее, по-прежнему используемые. Одним известным примером является ITunes от Apple для Windows. Здесь разработчики используют системные шрифты для GUI и, не заботясь о фактических размерах шрифта, они жестко привязывают размеры окон к разрешению 96 DPI, естественно искажая GUI, когда при более высоких значениях DPI увеличиваются размеры шрифтов.
Такие приложения требуют нового метод масштабирования «виртуализации DPI», к сожалению, это часто делает интерфейс размытым. В противном случае вы столкнетесь с проблемами начиная, от обрезания текста до перекрытия элементов контроля, иногда, делая GUI полностью непригодным (к счастью, это, случается редко). За эти годы я собрал несколько образцов скриншотов не корректных приложений.
разрешение 150% (144 DPI)
Приложения умеющие подстраивать свой GUI под различные значения DPI, имеющие DPI-Aware флаг — Это новейший тип приложений которые полностью беспроблемны, независимо от настроек DPI. DPI-Aware флаг установлен автоматически для Windows Presentation Foundation (WPF) и GDI+ приложений, так как эти APIs предоставляют встроенные средства масштабирования. Разработчикам использующим старый GDI API и (удивительно) Windows Forms, нужно вручную помечать свои DPI-Aware приложения.
Приложения не приспособленные к изменению DPI, но имеющие DPI-Aware флаг — это еще хуже чем полностью игнорирование значения DPI. В примерах вы найдете GUI приложений, хорошо масштабируемых вплоть до 120 DPI, но не выше, или приложений JavaFX. Тут мы уже ничего сделать не можем, т.к. у нас нет возможности заставить Windows использовать DPI виртуализацию, для таких программ. После того как DPI-Aware флаг установлен, приложение должно масштабировать себя самостоятельно. Мы можем только «пилить» разработчиков исправить их продукт — или использовать что-то другое.
Выбор метода масштабирования для ваших приложений
После того как вы решили что вы хотите использовать высокое значение DPI, ваш выбор метода масштабирования зависит от приложений в которых вы работаете. Имейте в виду, что, отключить «DPI виртуализацию» означает, установить флажок (check box) с некорректным названием «Использовать масштабы в стиле Windows XP» и наоборот.
Напоминаем, что в Windows 8.1 уже нет возможности выбора в этом вопросе. Если вы работаете при разрешении в 120 точек на дюйм (125%), каждая программа будет вынуждена использовать масштабирование в стиле Windows XP, a если вы работаете с более высоким разрешением, каждая программа, которая не является DPI-Aware, будет использовать по умолчанию «DPI виртуализацию».
Отказ от DPI виртуализации для отдельных приложений
После того как вы решили включить DPI виртуализацию или вы работаете в Windows 8.1, с разрешением более чем 120 точек на дюйм, вы можете проверить систему на предмет наличия DPI-Aware приложений, которые не имеют соответствующий флаг. И вернуть им возможность использовать масштабирование в стиле Windows XP, для которого они предназначены. Есть два способа сделать это, первый работает только для 32-разрядных приложений, второй универсален и подходит также для 64-битных приложений.
32-разрядные приложения — Это просто: щелкните правой кнопкой мыши на исполняемом файле в Проводнике Windows, выберите диалоговое окно «Свойства», перейдите на вкладку «Совместимость» и установите флажок «Отключить масштабирование изображения при высоком разрешении экрана». Вот и все, в Windows 8.1 это также работает для 64-битных приложений.
64-разрядные приложения — Без всякой видимой причины, возможно чтобы позлить пользователей 64-битных приложений, в Windows 8 и более ранних, упомянутый выше флажок, для 64-разрядных приложений отключен, хотя сам вариант вполне функционален, если внести изменения непосредственно реестр! Так что, запустите редактор реестра и перейдите к этому ключу:
Теперь добавьте строковое значение (REG_SZ), чье имя является полным путем к исполняемому файлу приложения и значением которого является HIGHDPIAWARE. Я рекомендую, чтобы вы сначала изменили несколько 32-битных приложений, как описано выше, чтобы вы могли увидеть некоторые примеры значений в этом ключе реестра.
Мы рассмотрели, как можно использовать настройки DPI на Windows Vista и более поздних версиях. И если вы когда-нибудь задумывались, для чего предназначена опция совместимости — «Отключить масштабирование изображения при высоком разрешении экрана». И почему она ничего не делает на вашей системе, теперь вы знаете: она эффективна, только если у вас включена общесистемная опция «DPI виртуализации» и только для приложений, которые не устанавливают DPI-Aware флаг должным образом, но при этом корректно используют масштабирование в стиле Windows XP.
Дальнейшее чтение
For more information about both scaling methods from a developer perspective, see the MSDN article Writing High-DPI Win32 Applications. This content has moved to Writing DPI-Aware Desktop and Win32 Applications. This lengthy article also contains a sample manifest to declare an application as DPI-aware, as well as sample screenshots for the various scaling methods and tips on display scaling in native code.
Unfortunately, the article currently only covers Windows XP through 7. See Writing DPI-Aware Desktop Applications in Windows 8.1 Preview (Word DOCX) and Chuck Walbourn’s Manifest Madness for additional information on Windows 8 and 8.1.
Outside of Microsoft, Gastón Hillar has published two articles targeting Windows 8.1 at Dr. Dobb’s. Part 1 covers basic concepts, and part 2 shows C/C++ sample code for the Win32 API.
Сложности современного масштабирования, часть 2
В этой части статьи речь пойдет о правилах масштабирования интерфейсов приложений в разных версиях Windows, а также о тех алгоритмах, которые применяет система.
Итак, в первой части статьи мы поговорили об основных сложностях, которые возникают при масштабировании интерфейсов. Это важно потому, что если мы понимаем, какие проблемы существуют и как они проявляются, то нам будет легче понять, чего хотел добиться в итоге производитель и почему он выбрал те или иные пути для достижения результата.
Далее речь пойдет о том, как работает масштабирование в операционных системах Windows, какие есть плюсы и минусы у существующих механизмов и насколько они готовы к работе с экранами с высокой плотностью пикселей.
DPI-aware: методики масштабирования приложений традиционного десктопа Windows
В большинстве случаев вина за сбои интерфейса при масштабировании лежит на разработчиках приложения. Ведь именно они должны проектировать интерфейс приложения так, чтобы он корректно отображался при разном уровне dpi. В идеале — использовать пропорциональные размеры и векторную графику. По данной теме существует довольно много материалов в помощь разработчкам, однако на практике большинство из них этим вопросом не занимаются, экономя собственные силы. Впрочем, об этом мы поговорим чуть ниже. А пока — пара примеров оттуда же: шрифт не помещается в отведенное пространство; некорректное отображение разных шрифтов.
В существующей парадигме открытой платформы Windows компания Microsoft не имеет возможности воздействовать на разработчиков, точнее — не имеет возможности требовать от них строгой оптимизации под масштабируемость. Остается действовать методом убеждения, даже несмотря на его низкую эффективность во многих случаях. Ситуация усугубляется тем, что сейчас на рынке появляется все больше дисплеев (в т. ч. и в ноутбуках), которые при настройке dpi=96 просто невозможно использовать, поэтому проблема масштабирования встает все более остро. При этом все шишки за некорректное масштабирование сыплются именно на Microsoft, что в значительной степени несправедливо.
У компании не было другого выхода, кроме как попытаться изобрести какое-то универсальное решение, которое работало бы независимо от приложения и позволяло исправлять огрехи разработчиков. Новый универсальный механизм масштабирования был представлен в Windows Vista, он же используется в современных версиях, 7 и 8. Его основной особенностью стала виртуализация dpi.
Разница между старым и новым методом состоит, грубо говоря, в следующем. Оба механизма позволяют выставить в системе глобальную настройку dpi: 96 (стандарт), 120 (увеличенный масштаб) либо пользователь может задать любой удобный ему масштаб вручную. А вот дальше начинаются различия: в традиционном механизме система сообщает приложениям текущий dpi и на этом умывает руки; как уже там приложение отмасштабируется — не ее дело. Новый механизм основан на оценке совместимости приложения. Приложение, которое оптимизировано и умеет правильно масштабироваться, должно само сообщить об этом системе (это и называется DPI-aware application). Для этого предусмотрено два способа: либо вызовом из программы, либо в манифесте. Но с первым способом возможны проблемы, если используется кэширование DLL (здесь описано подробнее), поэтому даже Microsoft не рекомендует его использовать. В случае, если приложение должным образом уведомило систему, ему предоставляются корректные данные о системной настройке dpi, и оно занимается масштабированием собственного интерфейса самостоятельно.
Если же приложение не сообщает о поддержке оптимизации, то задействуется стандартный алгоритм Windows, включающий механизм виртуализации dpi. Работает он следующим образом: система сообщает приложению, что dpi=96, т. е. оно работает в дефолтном масштабе. Исходя из этого, приложение формирует свое окно со всеми элементами в обычном режиме, после чего оно передается системе (в DWM, Desktop Window Manager; подробнее о его роли в масштабировании можно почитать, например, здесь) для вывода на экран. Особенность работы DWM состоит в том, что он сначала по полученным от приложений инструкциям рисует картинку, а потом уже в виде графики выводит ее на экран. Так вот, в случае, если приложение не имеет оптимизиации, то система сначала рисует его окно для дефолтного dpi, а потом самостоятельно масштабирует его до нужного размера (т. е. приводит его к глобальному dpi) и только после этого выводит на экран. В этот момент приложение воспринимается уже как картинка, т. е. размеры и взаимное расположение элементов жестко зафиксированы и не будут меняться. Основной плюс этого решения в том, что оно работает всегда и везде, для любого приложения и любого экрана.
Но есть и минусы, куда же без них. Во-первых, если приложение уже отрисовано под текущее разрешение, то после перемасштабирования оно может не помещаться на экран. Во-вторых, и это самое главное, при масштабировании картинки вверх возникают искажения и теряется четкость, прежде всего шрифтов. Для наглядности возьмите любую картинку в jpeg и попробуйте посмотреть на нее с масштабом 120-130%. А на экране это выглядит примерно вот так (96 и 192 dpi — это как раз то, что приложению сообщила система):
Итак, что получается: один механизм масштабирования был заменен на другой? Нет, это было бы слишком просто для Microsoft. В реальности система работает по гораздо более сложному и запутанному сценарию. На странице настройки (проще всего до нее добраться из окна управления разрешением экрана) нам доступны в принципе все те же параметры, что и в Windows XP, включая фиксированные настройки 100%, 125% и 150% (96 dpi, 120 dpi и 144 dpi), а также возможность свободного масштабировния виртуальной линейкой (это один из пунктов меню слева, так сразу и не догадаешься). И здесь же находится «волшебная» галочка XP style dpi scaling (в русской версии — «Использовать масштабы в стиле Windows XP», такой самостоятельный шедевр загадочного перевода), которая ответственна за существенную часть всей путаницы.
Самое забавное, что по умолчанию эта галочка включена, т. е. задействован именно «старый» механизм масштабирования ХР. Тут может возникнуть вопрос: а зачем городить огород с новым механизмом, если он по умолчанию отключен? Но на самом деле все не так однозначно: до определенного уровня масштабирования работает старый механизм, а дальше должен включаться новый. Однако момент переключения представляет собой загадку. Представители Microsoft весьма точно и однозначно объясняют, что старый алгоритм работает до 120 dpi, а новый начинает работать со 144 dpi. А между? Старый добрый Microsoft любит однозначность трактовок. В реальности все еще сложнее, это мы увидим при практическом тестировании.
В Microsoft, видимо, следовали следующей логике: разница между 96 dpi и 120 dpi не настолько значительная, чтобы нарушения в интерфейсе стали заметными. Зато огрехи масштабирования в «новом» алгоритме будут больше всего заметны именно в этом диапазоне. Поэтому если масштаб не сильно отличается от базового значения 96 dpi, то лучше оставить старый механизм масштабирования, который позволяет сохранить четкость векторных и системных элементов (в первую очередь, шрифтов). А уже при бо́льших отклонениях от стандарта — использовать новый. Собственно, именно этим объясняются многочисленные вопросы и жалобы на форумах, что после 120 dpi Windows ведет себя по-другому. Таким образом, для того чтобы включился новый механизм масштабирования, вам необходимо снять галочку или выставить масштаб больше, чем 120 dpi.
Что мы получаем в результате? Если приложение не умеет масштабировать свой интерфейс (или разработчики не занимались этим вопросом), то для любых настроек dpi система может самостоятельно масштабировать окно приложения так, чтобы оно выглядело более-менее пристойно. В результате пользователь сможет, несмотря на некоторые небольшие неудобства, работать с приложением в удобном ему масштабе.
Тем не менее, механизмы масштабирования операционной системы представляют собой некий аварийный вариант и должны задействоваться только в исключительных случаях. По общему правилу, приложение должно быть оптимизировано и корректно работать при самых разных настройках dpi. Разработчики должны изначально строить интерфейс так, чтобы он сохранял читаемость и расположение элементов даже при изменении масштаба.
Тем более что для обучения и коррекции было достаточно времени: мониторы со сверхвысокой плотностью пикселей выходят на рынок только сейчас, а агитация за правильные масштабируемые интерфейсы идет больше 10 лет, и за тот срок наработано много материалов и практических рекомендацией. Вот, например, гайдлайны по правильному созданию приложений с точки зрения масштабирования: на секундочку, 2001 год. Правильной работе интерфейсов при разном масштабе уделялось серьезное внимание в рамках Windows Presentation Foundation (WPF). В их гайдлайнах тоже есть много интересного. Подробнее можно почитать здесь: Википедия (англ), введение в WPF на MSDN и каталог ресурсов. Есть много других материалов, посвященных тому же, например этот.
Однако не умеющих правильно масштабироваться приложений до сих пор полно. То ли программисты не знают о доступных им возможностях, то ли банально ленятся. Причем отсутствует оптимизация в таких приложениях, что разработчики там должны были бы сгореть со стыда, типа iTunes для Windows или продуктов Adobe.
Впрочем, не стоит сваливать все только на разработчиков. В само́м механизме масштабирования Windows есть немало подводных камней, способных превратить оптимизацию приложения в веселый и познавательный, а главное — длительный процесс. Не говоря уже о некоторых откровенных багах (например, если в Windows 8 проставить галочку на злополучном XP style dpi scaling, то в следующий раз функция уже будет включена, но вот галочка стоять не будет). Или взять тот факт, что для работы этого механизма в Windows 7 должна быть включена функция Aero. Или, например, что Windows не будет менять размер несистемных шрифтов, которые могут использоваться в кастомизированных темах. Так что при использовании сторонних тем при изменении масштаба шрифты могут оказаться слишком большими или слишком маленькими. Или можно вспомнить примеры некорректной работы некоторых вроде бы системных элементов (вот один из примеров). В общем, выполнение всех гайдлайнов не гарантирует отсутствия проблем и уж тем более не отменяет необходимости тестирования с разными настройками dpi.
Сложности возникают даже с таким, казалось бы, простым элементом, как само уведомление об оптимизации (статус DPI-Aware). Про необходимость прямого указания в манифесте приложения мы писали выше, но не забыть это сделать — не единственная проблема. В идеале все выглядит просто: либо приложение поддерживает правильное масштабирование, либо нет. В реальной же жизни… В реальности часто встречаются и оставшиеся два варианта, в том числе когда интерфейс поддерживает правильное масштабирование, но флага в манифесте нет (потому что автор не знает, что его нужно ставить, или по каким-то причинам не стал его включать). В этом случае для приложения будет работать системный алгоритм масштабирования, хотя не должен — без него результаты были бы лучше. Причем юмор в том, что если выставить для проверки dpi = 120, все чудесно отмасштабируется и разработчик останется в уверенности, что все сделал правильно. Но стоит выставить 144 dpi…
Иногда бывает, что флаг стоит, а приложение правильно масштабироваться не умеет — либо все, либо какие-то элементы. В таких ситуациях флаг ставят, скорее всего, чтобы не включалась виртуализация и не замыливалась итоговая картинка, а на возможные проблемы с интерфейсом не обращают внимания, считая их незначительными. Это может быть необходимо, если в приложении идет работа с текстом, и вред от неправильного масштабирования перевешивает неудобство работы. Но если dpi будет слишком сильно отличаться от базового, то с интерфейсом просто невозможно будет работать, а система уже ничего сделать не сможет.
Кстати, у пользователей есть возможность выключать механизм виртуализации dpi не только для системы целиком, но и для отдельных приложений. Это может быть полезно как раз в таких пограничных ситуациях: когда по общему правилу виртуализация нужна (например, у вас экран со сверхвысоким PPI), а одному приложению она сильно мешает.
Только для этого его надо сначала включить (т. е. снять галочку с настройки XP Style scaling, как написано выше) для всей системы. Для 32-битных приложений масштабирование в стиле Vista/7 (т. е. виртуализацию dpi) можно выключить в настройках приложения (меню по правой кнопке мышки, в разделе «совместимость») — там есть специальная галочка. А вот для 64-битных так почему-то не сделаешь (функция отключена, спасибо специалистам Microsoft), там придется повозиться. Нужно зайти в реестр, в этот ключ:
Добавить строчную переменную string value (REG_SZ) с именем в виде полного пути к файлу приложения, а параметр выставить в HIGHDPIAWARE. Чтобы яснее понимать, как эти ключи выглядят, сначала лучше посмотреть, как это работает с 32-битными приложениями (там ключ создается автоматически при установке галочки).
Таким образом, качество работы приложения при изменении системного dpi во многом зависит от того, насколько грамотно оно сделано и насколько учитывает возможность масштабирования интерфейса. Windows, со своей стороны, имеет сложный механизм самостоятельного масштабирования приложений, который должен обеспечить некий средний уровень удобства работы с приложением даже в том случае, если самостоятельно оно масштабируется некорректно.
Windows 8: подход новый, проблемы старые
Новый интерфейс (и новая модель приложений в общем) дал Microsoft уникальную возможность: создать новую концепцию масштабируемого интерфейса, которая была бы избавлена от груза совместимости и накопленных ошибок и при этом учитывала бы и плюсы традиционного подхода, и накопленный опыт в создании современных интерфейсов для мобильных устройств. Плюс, новая система должна быть простой и удобной — как для создателей приложений и интерфейсов, так и для пользователей.
Тем более что насущная потребность в правильном и универсальном алгоритме масштабирования была одним из краеугольных требований к системе. Легко Apple: всего два разрешения, да еще и с простой двукратной разницей. Мелочи жизни! Windows 8 должна хорошо работать на уже существующих устройствах, у которых комбинаций разрешение/размер было штук пятнадцать, и при этом постоянно появляются новые, а старые сходят со сцены. Кроме того, не стоит забывать про нарастающее давление производителей устройств, которым необходима поддержка экранов с высокой плотностью пикселей, обеспечивающих гладкие линии и шрифты и пр. Причем не просто поддержка, а качественная поддержка!
Для начала поговорим о доступных разрешениях. Изначально минимальным полноценно рабочим разрешением (при котором поддерживаются все функции) для Windows 8 было установлено 1366×768. Согласно логике разработчиков, доля экранов с меньшим разрешением пренебрежимо мала (в районе 1%) и продолжает падать. В то же время оптимизация приложений под интерфейс с низким разрешением может представлять собой серьезные сложности и существенные дополнительные затраты для разработчиков — по крайней мере, так изначально объясняли свою позицию в Microsoft.
Однако слабый старт системы, видимо, заставил компанию немного пересмотреть свои взгляды, и сейчас вроде бы в качестве минимального разрешения установлено 1024×600, чтобы дать возможность производителям выпускать с Windows 8 даже 7-дюймовые планшеты. Очень спорное, на мой взгляд, решение, но сейчас вообще такой момент, что без риска не выживешь.
Впрочем, несмотря на то, что минимальным полноценным разрешением ранее было объявлено 1366×768, интерфейс приложений должен показываться корректно при минимальном разрешении 1024×768. Последнее требование появилось из-за технологии Snap.
В новом интерфейсе Windows 8 приложения всегда разворачиваются на весь экран, оконного режима просто нет. Благодаря технологии Snap экран можно разделить между двумя приложениями: одно, полноценно работающее, разворачивается на 2/3 экрана, а второе, вспомогательное — на оставшуюся треть. Работающее в режиме Snap приложение ограничено по горизонтали 320 пикселями, и при разрешении экрана 1366×768 приложения поделят его на 1024 и 320 пикселей. Кстати, если разрешение экрана меньше минимально допустимого, например 1280×800, то Snap не будет работать.
Пропорции разделения экрана для Snap жестко заданы, свободно перераспределять место нельзя (в следующей версии, Windows Blue, обещают возможность делить экран пополам). Это, по словам Microsoft, тоже сделано для упрощения жизни разработчиков: они могут один раз нарисовать интерфейс для жестко заданного соотношения сторон и не волноваться, что с ним случится при свободном изменении ширины окна.
В качестве максимального разрешения на данный момент указано 2560×1600, однако система будет корректно работать и с экранами с более высоким разрешением. Хотя я с трудом представляю себе логику, согласно которой приложения на экране с диагональю 30 дюймов и таким разрешением должны раскрываться только на полный экран. Чем этот экран занять? Возможно поэтому Microsoft говорит не о сопутствующем росте физического размера экранов, а скорее об увеличении плотности пикселей, приводя в качестве примеров планшеты с экранами 11,6 дюйма (Microsoft просто никак не может от них оторваться) с разрешением Full HD, а дальше рассчитывает на появление устройств Quad-XGA, 2560×1440 при диагонали 11,6 дюйма (253 PPI).
Раз уж все параметры являются произвольными, значит система должна корректно работать с любой диагональю, разрешением и плотностью пикселей, а в идеале — сама подбирать все нужные параметры интерфейса, включая масштаб, исходя из физических характеристик конкретного экрана.
Именно этот сценарий реализован для Windows 8 (кстати, Windows 7 тоже умеет выставлять масштаб в зависимости от монитора, но там ОС выбирает, насколько я понял, из двух значений: 96 и 120 dpi). Информацию о разрешении, размере и параметрах монитора ОС получает из расширенной информации EDID, которую предоставляет сам монитор (подробнее в википедии (англ), также есть тема на нашем форуме, которая хорошо иллюстрирует, насколько все непросто). Исходя из полученных данных, система оценивает сочетание параметров монитора и выбирает оптимальный размер виртуального DPI (масштабирования), при котором размер элементов и шрифтов близок к оптимальному. Причем делает это в полностью автоматическом режиме.
Настройки являются глобальными для системы и применяются ко всем приложениям; насколько я понял, выставить для одного приложения другие параметры нельзя (хотя, вполне вероятно, в недрах реестра такая возможность закопана). Также нельзя поменять вручную размер шрифта, чтобы при этом размеры картинок, плиток и т. д. остались неизменными. С одной стороны, такая настройка могла бы быть весьма полезной (например, в ситуации, когда размеры плиток в меню вас устраивают, а шрифт кажется мелковатым). С другой, велик риск порушить весь внешний вид интерфейса.
Другими словами, речь опять идет не о свободном масштабировании, а о неких фиксированных величинах. Причем какой именно масштаб использовать — решает система в автоматическом режиме. Здесь можно посмотреть таблицу соотношения параметров разрешение/dpi.
Microsoft утверждает, что и это решение в первую очередь выгодно разработчикам приложений, т. к. упрощает им жизнь. Теперь достаточно проверить работоспособность интерфейса в трех положениях, и если он показывается нормально, то ваше приложение всегда будет выглядеть хорошо. В режиме десктопа, где доступно свободное масштабирование, оптимизировать интерфейс сложнее. Поэтому чаще всего разработчики ограничивались тем, что оптимизировали интерфейс под 96 dpi, делали более-менее нормальную реакцию на растягивание окна — и ладно.
Даже несмотря на то, что масштабов всего три, Windows предлагает два варианта дизайна. Лучше использовать векторные форматы для отображения шрифтов и графических элементов — тогда система сама всегда сможет отмасштабировать их до нужного уровня. В качестве нового пути Microsoft предлагает средства XAML и CSS, особо упирая на то, что это открытые и общепринятые стандарты. Использование векторной графики позволяет гарантировать, что интерфейс будет качественно масштабироваться под любой экран. Второй путь — разработчик может приготовить три набора графических элементов под каждый масштаб, а система (при правильном оформлении внутри приложения) выберет нужный.
С технической точки зрения жизнь разработчика становится проще: теперь Windows 8 берет на себя бо́льшую часть работы, связанной с масштабированием, отрисовкой элементов и пр. Иначе говоря, технически стало проще. С другой стороны, на мой взгляд, с точки зрения концепции стало сложнее: раз уж система «работает одинаково» на всех устройствах, начиная от 10-дюймового планшета и заканчивая 27-дюймовым десктопом (и разрешениями от 1024×768 до 2560×1600), то разработчику нужно так извернуться, чтобы интерфейс нормально выглядел на любом из этих разрешений с точки зрения и организации, и информационной насыщенности. Ах да, и чтобы пальцем работать было удобно на любом из них. Тем более что, напомню, концепция современного (метро-) интерфейса предполагает, что приложения разворачиваются всегда на полный экран, окон с «произвольным масштабом», как на десктопе, там не бывает.
Microsoft предлагает разработчикам на выбор два основных пути организации интерфейса приложения. Первый — адаптивное масштабирование.
Условно говоря, у вас есть заданный оптимальный размер элементов и шрифтов, и при росте разрешения у вас будет расти количество элементов, которые влезают на экран. В метро-интерфейсе новые элементы чаще появляются не ниже существующих, а правее, и лента прокручивается по горизонтали. На современных мониторах стандарта 16:9 такая организация должна позволить более эффективно использовать площадь экрана.
Второй вариант — фиксированный набор элементов.
Этот вариант предполагает, что количество и взаимное расположение элементов на экране фиксировано, и с ростом разрешения (размера) экрана они просто увеличиваются в размере. Microsoft в качестве примера такого интерфейса приводит шахматную доску. Действительно, в этом случае вам необходимо видеть все поле независимо от масштаба, и нет никаких дополнительных элементов, которые имело бы смысл размещать на экране при появлении дополнительного места.
Есть и другие случаи: например, если управление в игре сделано в виде картинок на экране, то при росте разрешения они должны оставаться на своем месте и иметь примерно тот же размер. В этом случае удобно, что есть всего три фиксированных масштаба — легко можно оптимизировать внешний вид приложения под любой из них.
Таким образом, для нового интерфейса Microsoft предлагает новый подход к масштабированию системы и приложений, причем подход системный и логичный. Во многом он избавляет разработчиков от головной боли, связанной с необходимостью оптимизации интерфейса под разные размеры, разрешения экрана и пр.: им достаточно следовать простым правилам, чтобы приложение всегда работало корректно. При этом у них есть и описание системы, и учебные материалы с примерами, и нужный инструментарий.
С другой стороны, этот подход загоняет разработчиков в жесткие рамки, которые во многих случаях не позволят им реализовать все задуманные возможности. Но к чему привела свобода творчества, мы уже видели на примере десктопа. Просто там у Microsoft нет инструментов давления на разработчиков, а вот в отношении приложений под новый интерфейс — есть. Те приложения, которые не удовлетворяют требованиям Microsoft, просто не попадут в магазин приложений Microsoft Store, а это единственный существующий способ вообще установить их в систему пользователя.
Некоторые промежуточные итоги
Надеюсь, благодаря первым двум статьям читатели смогли составить для себя впечатление о том, как работают механизмы масштабирования в современных версиях операционной системы Microsoft Windows. Давайте суммируем информацию.
Основная проблема при масштабировании интерфейса состоит, грубо говоря, в том, что для разных элементов используются разные единицы измерения, поэтому при изменении масштаба их размеры друг относительно друга меняются. Плюс, практически все приложения частично используют собственные ресурсы, а частично — ресурсы системы, это тоже вносит путаницу. В результате, в традиционном интерфейсе Windows, т. е. на старом добром десктопе, корректное масштабирование интерфейса приложений в значительной степени зависит от воли разработчиков приложений — насколько они учтут возможность изменения масштаба интерфейса при его разработке.
Это один из тех случаев, когда легкость взаимодействия и открытость традиционной платформы Windows, Win32, позволившие ей завоевать огромную популярность в мире, оборачиваются против нее. Платформой пользуется громадное количество разработчиков с самым разным уровнем знаний, многие из которых либо не знают о ее требованиях и особенностях, либо сознательно игнорируют их из-за лени или по другим причинам. При этом из-за открытости платформы и свободы программирования под нее у разработчика Windows, компании Microsoft, практически нет средств принуждения, позволяющих поддерживать стандарт качества ПО и корректную работу в разных условиях, остается действовать через рекомендации и побуждения, а их эффективность традиционно невысока. И при этом, что самое обидное, все ошибки в работе списывают именно на операционную систему.
Современные версии Windows предлагают два алгоритма масштабирования: старый, который управляет масштабом системных элементов, но оставляет масштабирование собственных ресурсов приложения на его усмотрение, и новый (впервые представленный в Windows Vista), который, благодаря виртуализации dpi, позволяет сохранить интерфейс приложения в полностью оригинальном виде при любом масштабе — пусть и ценой некоторого ухудшения качества изображения.
Приложение, умеющее корректно масштабировать интерфейс, должно сообщать об этом системе. Те приложения, которые не оптимизированы таким образом, до определенного масштаба будут работать в рамках старого алгоритма, а далее включится новый. Это связано с особенностями их работы: при небольшом увеличении масштаба разумнее использовать старый алгоритм масштабирования, т. к. сохраняется четкость шрифтов и мелких элементов, а ошибки построения интерфейса не так заметны. При большом масштабе лучше использовать новый алгоритм, т. к. сохраняется визуальное строение интерфейса, а размытость при большом масштабе не так бросается в глаза.
Тем не менее, масштабирование силами системы — это костыли, компенсирующие недоработки создателя приложения, но не позволяющие добиться оптимального результата. Так что корректность работы интерфейса при нестандартном масштабе в значительной степени зависит от разработчика приложения. И если он не уделил этому внимания, то пользователь столкнется либо с проблемами отображения интерфейса, либо с ухудшением его внешнего вида.
Учитывая масштаб проблемы, в Microsoft предприняли ряд серьезных шагов, направленных на то, чтобы в новом интерфейсе ситуация не повторилась. Возможности создателей приложений под новый интерфейс существенно ограничены необходимостью соблюдения жестких требований по оформлению приложения, в том числе и касающихся масштабирования. Поэтому, с одной стороны, новая платформа и новый интерфейс Windows 8 предлагают разработчикам четкие и простые правила, а также и новые мощные инструменты. Все это позволяет существенно облегчить им жизнь: с создателей приложений снимается существенная часть технической работы и решения различных прикладных проблем. В то же время новая платформа существенно ограничивает возможности разработчиков и ставит их в гораздо более жесткие рамки при решении стоящих перед ними задач. Кроме того, здесь компания Microsoft имеет серьезный инструмент контроля: приложения для нового интерфейса, не соответствующие требованиям, просто не будут допущены в магазин Windows Store. А установить приложения можно только из этого магазина.
В результате создается впечатление, что ситуация с масштабированием в Windows детально проработана и выверена. Однако это все теория. На практике же проблем, в том числе связанных с масштабируемостью интерфейсов системы и приложений, намного больше. И не всегда они связаны только с приложениями: иногда речь идет о некорректной работе системных функций либо специфического сочетания функций приложения, драйверов, компонентов и функций системы или других вещей. Да что там: несмотря на всю простоту и ясность, и у приложений под новый интерфейс также часто бывают проблемы (неработоспособность, зависания, вылеты), и хотя здесь они практически никогда не могут навредить системе (в отличие от десктопа), но все-таки говорить о стабильности работы пока рано. Уверен, что и в самой системе ошибки еще есть.
Тем не менее, в Microsoft проделали неплохую работу, создав вполне работоспособный механизм масштабирования, позволяющий работать на экранах с высокой плотностью пикселей даже в старых приложениях, не имеющих оптимизации под таковые.
В следующей, третьей части цикла статей мы как раз попробуем заняться практикой и посмотрим, как масштабирование интерфейсов приложений работает в реальной жизни, а также перейдем к глобальным выводам, т. е. поговорим о том, к чему нас приведет развитие схем масштабирования Windows, внедрение дисплеев с высокой плотностью пикселей и пр.
