В этой части статьи речь пойдет о правилах масштабирования интерфейсов приложений в разных версиях Windows, а также о тех алгоритмах, которые применяет система.
Итак, в первой части статьи мы поговорили об основных сложностях, которые возникают при масштабировании интерфейсов. Это важно потому, что если мы понимаем, какие проблемы существуют и как они проявляются, то нам будет легче понять, чего хотел добиться в итоге производитель и почему он выбрал те или иные пути для достижения результата.
Далее речь пойдет о том, как работает масштабирование в операционных системах Windows, какие есть плюсы и минусы у существующих механизмов и насколько они готовы к работе с экранами с высокой плотностью пикселей.
DPI-aware: методики масштабирования приложений традиционного десктопа Windows
В принципе, ОС Windows уже давно имеет возможность масштабировать интерфейс, в т. ч. посредством изменения dpi. До Windows ХР включительно эта технология работала следующим образом. Приложение может либо полностью самостоятельно готовить содержимое своего окна и уже потом передавать его в систему для отрисовки (в GDI), либо частично использовать собственные ресурсы, а частично — ресурсы системы. Большинство приложений пользуются теми или иными ресурсами системы, так проще и удобнее для разработчиков. При этом ресурсы системы, разумеется, оптимизированы производителем для корректного масштабирования. Что же касается собственных ресурсов приложения, то о них должен позаботиться разработчик. Это, в общем-то, логично. Однако в мире существует огромное количество программ, компоненты которых ведут свою родословную с замшелых годов, когда о масштабировании интерфейса и его элементов никто не думал. И еще больше в мире программистов и разработчиков, которые не осознают/не могут/ленятся учитывать возможность масштабирования при создании интерфейсов своих приложений. В результате интерфейс приложения может красиво и целостно смотреться при dpi=96, но стоит изменить этот параметр, как элементы полезут друг на друга, текст перестанет помещаться в предназначенные для него места и т. д. Некоторые примеры описаны в инструкции Microsoft по оптимизации приложений под масштабирование. Они довольно очевидны, поэтому перечислим основные:
- элементы не помещаются на свое место в интерфейсе;
- шрифт слишком большой или слишком маленький;
- нарушено расположение элементов;
- размытые элементы интерфейса;
- пикселизированные элементы интерфейса;
- неправильное расположение элементов, влияющее на ввод;
- частичное отображение полноэкранного приложения;
- неправильное использование эффективного разрешения.
В большинстве случаев вина за сбои интерфейса при масштабировании лежит на разработчиках приложения. Ведь именно они должны проектировать интерфейс приложения так, чтобы он корректно отображался при разном уровне 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), там придется повозиться. Нужно зайти в реестр, в этот ключ:
HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionAppCompatFlagsLayers
Добавить строчную переменную 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 (масштабирования), при котором размер элементов и шрифтов близок к оптимальному. Причем делает это в полностью автоматическом режиме.
Настройки являются глобальными для системы и применяются ко всем приложениям; насколько я понял, выставить для одного приложения другие параметры нельзя (хотя, вполне вероятно, в недрах реестра такая возможность закопана). Также нельзя поменять вручную размер шрифта, чтобы при этом размеры картинок, плиток и т. д. остались неизменными. С одной стороны, такая настройка могла бы быть весьма полезной (например, в ситуации, когда размеры плиток в меню вас устраивают, а шрифт кажется мелковатым). С другой, велик риск порушить весь внешний вид интерфейса.
Судя по форумам, проблемы с автоопределением в основном встречаются у HTPC, подключенных к телевизорам, т. к. телевизоры не выдают EDID и операционная система не может правильно определить параметры экрана. В этом случае пользователям приходится настраивать параметры метро-интерфейса отдельно. Для этого есть несколько вариантов:
- Панель управления — ease of access, и там увеличить изображение. Работает только для метро-интерфейса.
- Прямое исправление диагонали экрана в реестре, все достаточно очевидно, но если хотите лезть в реестр — на свой страх и риск.
- Стороннее ПО (как обычно).
В предыдущем разделе мы уже выяснили, что у десктопа есть фактически четыре настройки:
- 100%/96 dpi
- 125%/120 dpi
- 150%/144 dpi
- Свободное масштабирование интерфейса «по линейке»
Что касается нового интерфейса Modern UI (ex-Metro), то для него Microsoft предлагает три базовых формата:
- 100%
- 140%
- 180%
Другими словами, речь опять идет не о свободном масштабировании, а о неких фиксированных величинах. Причем какой именно масштаб использовать — решает система в автоматическом режиме. Здесь можно посмотреть таблицу соотношения параметров разрешение/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, внедрение дисплеев с высокой плотностью пикселей и пр.
