И еще раз о высоком разрешении

Наша предыдущая статья положила начало очень живой дискуссии по поводу высоких DPI. Большинство комментариев к статье отлично согласуются с собранной нами статистикой. Для тех областей, где у нас нет данных, комментарии подтвердили многие из существующих ранее предположений. Что-то читатели недопоняли, где-то додумали, как все должно быть. Поэтому данная статья носит характер ответа на комментарии пользователей, а также с ее помощью мы надеемся пролить свет на те моменты, которые привели пользователей в некое замешательство.

Вот краткий перечень наших умозаключений, отраженных в комментариях пользователей к предыдущей статье:

• Большинство пользователей меняют разрешение экрана чтобы увеличить размер шрифта или делают это случайно
• Есть группа пользователей, которые отлично осознают назначение функции "high DPI" и осознанно пользуются ей
• Некоторые пользователи предпочитают иметь больше свободного пространства, а некоторым нравятся крупные элементы UI
• Найти настройку DPI — для некоторых весьма нетривиальная задача
• Совместимость приложений является распространненной проблемой, в некоторых случаях определяющей при выборе разрешения
• Масштабирование в IE является одной из самых распространенных проблем (в IE8 большинство из этих проблем решены)
• Большинству пользователей достаточно сложно объяснить предназначение этой функции

Из комментариев также стало ясно, что многие пользователи не знают ответы на следующие вопросы:

• Правда ли то, что если применять векторный интерфейс, то все эти проблемы исчезнут?
• А нельзя ли сделать так, чтобы разработчикам ничего не нужно было делать?
• В чем отличие от таких технологий, как масштабирование в IE?
• Можно ли использовать DPI для калибровки или данная функция предназначена лишь для масштабирования?

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

Векторная графика против растровой

В компьютерном мире всегда существовал миф о “серебряной пуле”, которая решает все проблемы и в значительной степени упрощает жизнь пользователям, разработчикам и дизайнерам. В комментариях к оригинальной статье некоторые пользователи предлагают нам сделать интерфейс ОС полностью векторным, что по их мнению должно решить проблему с масштабированием. Как оказалось, при использовании векторной графики возникают некоторые проблемы, которые требуют объяснения.

Проблема состоит в том, что при использовании маленьких иконок, лучше менять представление, чтобы их значение стало очевидным. Обратите внимание на иконки ниже. В данном случае для самого маленького размера иконки дизайнер предпочел использовать фронтальный вид, а не перспективный.

Это все потому, что дизайнеру показалось, что при таком маленьком размере иконки наиболее наглядным будет именно фронтальный вид. Вот еще один пример, иллюстрирующий эту точку зрения:

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

Однако, даже в случае, когда используется один векторный источник, дизайнеры проводят подгонку для разных размеров, чтобы конечный результат в точности соответствовал задуманному. Только представьте векторное изображение линии шириной в 1 пиксель на разрешении 128x128, которое было масштабировано до разрешения 64x64. Мониторы не могут корректно отобразить линии шириной в 1/2 пикселя! В большинстве случаев монитор попросту “округлит” 1/2 до одного пикселя. Однако, это до неузнаваемости преобразит разметку элементов изображения. Как узнать, какую пиксельную линию округлять и в какую сторону? Если дизайнер хорошенько не продумает этот момент, то решение ляжет на плечи механизма визуализации, что сулит появление непредвиденных результатов. Кто-то скажет, что можно определить правила, регулирующие, какие конкретно элементы должны быть в векторной графике, но это еще более ограничивает применение такого подхода.

Оказывается, что даже TrueType-шрифты, используемые в Windows, снабжены размеро-зависимой информацией. Основная часть конвейера визуализации TrueType-шрифтов построена на алгоритмическом масштабировании векторного источника, но, тем не менее, они размеро-зависимы: в шрифты вкраплены в некотором роде подсказки, указывающие системе, каким образом прорисовывать, к примеру, углы в случаях, когда линии попадают между границами пикселей. Подробнее об этом можно узнать по адресу: https://blogs.msdn.com/fontblog/archive/2005/10/26/485416.aspx

Неправда и то, что векторная графика всегда меньше в размере (особенно для маленьких изображений). Как правило, для создания векторной графики дизайнеры используют специальные редакторы, позволяющие строить изображение послойно с добавлением различных эффектов. В случае растровых изображений дизайнеры объединяют слои до того, как сделать конкретное изображение элементом своего приложения. Большинство современных дизайнеров уделяют мало внимания размеру слоев, поскольку при их объединении получается изображение с фиксированными размерами. Но случае векторной графики не существует техник объединения слоев, поэтому дизайнерам приходится думать об используемых эффектах, чтобы избежать создания огромных по объему занимаемого дискового пространства иконок. Я вместе с одним из наших дизайнеров потратил некоторое время на создание векторной реализации одного растрового изображения. Итоговый размер иконки составит 622 Кб! Да, конечно, этот размер фиксирован и одинаков для любого разрешения, но этот же файл можно с легкостью пересохранить, как PNG размером всего 23 Кб.

Безусловно, можно было бы довести до ума файл с векторной графикой, в значительной степени сократив его размер, если бы время на эту операцию было предусмотрено планом разработки. Но это бы стало еще одним ограничением, накладываемым на дизайнера.

Чем мы можем помочь разработчикам?

Для тех приложений, где требуется серьезный контроль над разметкой и графикой, или используется масштабирование изображений в пределах доступных разрешений, знание расположения пикселей среди элементов интерфейса крайне важно для получения наилучшего результата. Это требование применимо как обычным ПК, так и к Mac'ам (для информации см. https://developer.apple.com/releasenotes/GraphicsImaging/RN-ResolutionIndependentUI/). Существует мнение, что если дать разработчикам необходимый инструментарий или среду разработки, все проблемы исчезнут сами собой. Все мы знаем, что любой набор инструментов или инфраструктура предполагает наличие компромиссов (будь то Win 32, .NET или HTML). И несмотря на то, что серебрянной пули нет, есть несколько трюков, которые могут в значительной степени облегчить создание DPI-независимых приложений. Об этом мы подробно расскажем на грядущих конференциях. Кроме того, мы поведаем о том, как без особых трудностей сделать существующие приложения DPI-независимыми. На первой конференции - Microsoft Professional Developer Conference — о функции "High DPI" будет рассказано в ходе сессии “Writing your Application to Shine on Modern Graphics Hardware (ссылка)”. Что касается второй - Windows Hardware Engineering Conference - обсуждению функции будет отведено время сессии “High Fidelity Graphics and Media” (ссылка).

Решение проблем программной совместимости

Некоторые пользователи подняли в комментариях вопрос программной совместимости. Иногда проблем с совместимостью можно избежать путем включения или выключения функции автоматического масштабирования. Глобально это можно изменить через интерфейс настройки DPI, щелкнув на кнопке “Custom DPI” и поставить галочку на опции “Use Windows XP style DPI scaling”. Когда эта функция отключена, приложения, которые не заявлены как DPI-независимые, автоматически масштабируются менеджером окон. Когда опция отмечена, автоматическое масштабирование отключено глобально. Следует отметить, что при настройках DPI, меньших 144 DPI, данная опция включается автоматически, а для настроек выше 144 DPI — по умолчанию отключена. В некоторых случаях смена настроек по умолчанию может оказать положительный эффект, но это зависит от используемых приложений и настроек DPI. Также достоен внимания и тот факт, что функция автоматического масштабирования может быть отключена для каждого приложения в отдельности через закладку Program Compatibility в свойствах ярлыка к приложению. О том, как это сделать, можно прочитать здесь — https://windowshelp.microsoft.com/Windows/en-US/help/bf416877-c83f-4476-a3da-8ec98dcf5f101033.mspx. (раздел “Disable Display Scaling on high DPI settings”)

В чем отличия масштабирования DPI от таких технологий, как IEZoom ?

Интерфейс типичного приложения состоит из контент-окна, в котором размещено непосредственное содержимое (в IE это сама веб-страница), и фрейма, в котором располагаются меню и панели. Как оказалось, код для поддержки масштабирования при переходе к более высоким DPI в контент-окне полностью соответствует коду, используемому для стандартного масштабирования. На самом деле, для настройки коэффициента масштабирования контент-окон IE8 использует настройки DPI (см. статью DPI Scaling and Internet Explorer 8). Тем не менее, переход к большим значениям DPI имеет в качестве побочного эффекта масштабирование окна фрейма UI. Поскольку большинство пользователей используют масштабирование для увеличения размера шрифтов, что позволяет сделать их более удобочитаемыми, вполне логично масштабировать и размер фрейма, так как текст меню и панелей в таком случае тоже масштабируются. В случае настройки масштабирования для каждого приложения в отдельности имеет место масштабирование лишь контент-окна. Масштабирование DPI позволяет одинаково визуализировать элементы интерфейса всех приложений без исключения.

Можно ли использовать DPI для калибровки экрана?

Некоторые пользователи предлагают использовать функцию "high DPI" в качество способа для калибровки экрана, чтобы физический размер объекта не зависел от экрана. Да, мы думали об этом, но проблема в том, что это не решит проблему пользователей, которые хотят иметь возможность настраивать размер текста и элементов интерфейса. Если бы была определена “глобальная шкала”, это бы означало, что разработчикам приложений пришлось бы уделять внимание обеим метрикам, а это в значительной степени усложнило бы их работу. Более того, если пользователь чувствует, что UI слишком мал, кто должен определять – разработчик или пользователь, – насколько большим должен быть интерфейс? Другими словами, если дизайнер считает, что конкретная кнопка должна быть размером в один сантиметр, но по мнению пользователя та же самая кнопка должна быть размером в 1,5 сантиметра, чье мнение должно быть решающим? На текущий момент пользователь может настроить интерфейс на свой лад, но лишь разработчик может обеспечить максимальное качество графики при конкретных настройках.

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

Райан Хэвсон (Ryan Haveson)
программный менеджер Windows Desktop Graphics