Вот кстати не пойму, накой надо было уменьшать пикселы, неужели кому-то они казались слишком большими?
Интересно, они уже починили отот баг, когда ты через 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к с соответствующей диагональю(за исключением некоторых ноутов с хайдпи экранами)
Desktop applications on Windows can run in different DPI awareness modes. These modes enable different DPI scaling behavior and can use different coordinate spaces. For more information on DPI awareness, see High DPI Desktop Application Development on Windows. It is important that you explicitly set the default DPI awareness mode of your process so as to avoid unexpected behavior.
There are two main methods to specify the default DPI awareness of a process:
1) through an application manifest setting
2) programmatically through an API call
We recommended that you specify the default process DPI awareness via a manifest setting. While specifying the default via API is supported, it is not recommended.
Setting default awareness with the application manifest
The table below shows how to specify different process-default DPI awareness modes using the two manifest settings:
Process default DPI awareness mode
setting
setting (WindowsВ 10, version 1607 and later)
unaware
N/A (no dpiAware setting in manifest)
unaware
System aware
true
system
Per Monitor
true/pm
PerMonitor
Per Monitor V2
Not supported
PerMonitorV2
The sample below shows both the and the settings being used within the same manifest file to configure process-default DPI awareness behavior for different versions of Windows.
Setting default awareness programmatically
Although it is not recommended, it is possible to set the default DPI awareness programmatically. Once a window (an HWND) has been created in your process, changing the DPI awareness mode is no longer supported. If you are setting the process-default DPI awareness mode programmatically, you must call the corresponding API before any HWNDs have been created.
There are multiple APIs that let you specify the default DPI awareness for your process. The current recommended API is SetProcessDpiAwarenessContext, as older APIs offer less functionality.
This document refers to setting the default DPI awareness for your process. This is because Windows 10 introduced support for running more than one DPI awareness mode within a single process (prior to Windows 10, the entire process had to conform to a single DPI awareness mode). Support for running more than one DPI awareness mode within a process is referred to as «mixed-mode DPI scaling». When using mixed-mode DPI scaling within your process, each top-level Window can run in a DPI awareness mode that may be different than that of the process default. Unless explicitly specified, each thread will default to the process default when created. For more information about mixed-mode DPI scaling, refer to the Mixed-Mode DPI Scaling article.
чтобы эффективно программировать с помощью Windows графики, необходимо разобраться с двумя связанными понятиями:
Начнем с DPI. Для этого потребуется краткий обзор типографии. В типографии размер типа измеряется в единицах, именуемых points. Одна точка равна 1/72 дюйма.
Это определение точки публикации на настольном компьютере. Исторически точная мера точки изменилась.
Например, шрифт 12-точечного шрифта помещается в строку текста 1/6 «(12/72). Очевидно, что это не означает, что каждый символ в шрифте ровно 1/6 «высокий». На самом деле некоторые символы могут быть больше, чем 1/6. Например, во многих шрифтах символ a больше, чем номинальная высота шрифта. Для правильного вывода шрифта требуется дополнительное пространство между текстом. Это пространство называется ведущим.
На следующем рисунке показан шрифт 72-пт. В сплошных линиях вокруг текста отображается 1 «ограничивающий прямоугольник». Пунктирная линия называется базовой. Большая часть символов в шрифте, оставшаяся в базовом плане. Высота шрифта включает часть, расположенную выше базовой линии ( восхождение), и часть, расположенную ниже базовой линии ( спуск). В показанном здесь шрифте восхождение составляет 56 точек, а спуск — 16 пунктов.
Однако, когда дело доходит до экрана компьютера, измерение размера текста является проблематичным, так как в пикселях используется не тот же размер. Размер пикселя зависит от двух факторов: разрешения экрана и физического размера монитора. Таким образом, физические дюймы не являются полезной мерой, так как нет фиксированной связи между физическими дюймами и пикселями. Шрифты измеряются в логических единицах. Шрифт в 72 пт определяется как один логический дюйм в высоту. Затем логические дюймы преобразуются в пиксели. в течение многих лет Windows использовалось следующее преобразование: один логический дюйм равен 96 пикселов. При использовании этого коэффициента масштабирования шрифт 72-пт выводится в высоту 96 пикселей. Высота 12-точечного шрифта составляет 16 пикселей.
Этот коэффициент масштабирования описан как 96 точек на дюйм (DPI). Термин точки наследуется от печати, где на бумаге помещаются физические точки рукописного ввода. Для дисплеев на компьютере было бы более точным, например, 96 пикселей на логический дюйм, но в этом случае это означает, что точка DPI была задержана.
Так как фактические размеры пикселей различаются, текст, который может быть прочитан на одном мониторе, на другом мониторе могут быть слишком маленьким. Кроме того, люди имеют разные предпочтения — некоторые люди предпочитают текст больше. по этой причине Windows позволяет пользователю изменить параметр DPI. Например, если пользователь устанавливает для дисплея значение 144 DPI, то шрифт 72-пт составляет 144 пикселей в высоту. Параметры стандартного DPI: 100% (96 точек на дюйм), 125% (120 DPI) и 150% (144 DPI). Пользователь может также применить настраиваемый параметр. начиная с Windows 7 DPI — это параметр для каждого пользователя.
Масштабирование DWM
Если программа не учитывает DPI, то следующие дефекты могут быть очевидны при высоком уровне DPI:
Чтобы обеспечить работу старых программ в параметрах с высоким разрешением, DWM реализует полезную резервную копию. Если программа не помечена как учитывающая DPI, DWM будет масштабировать весь пользовательский интерфейс в соответствии с параметром DPI. Например, при 144 DPI пользовательский интерфейс масштабируется по 150%, включая текст, графику, элементы управления и размеры окон. Если программа создает окно 500 × 500, окно отображается как 750 × 750 пикселей, а содержимое окна масштабируется соответствующим образом.
Такое поведение означает, что старые программы работают только в параметрах с высоким разрешением. Однако масштабирование также приводит к частично размытому внешнему виду, так как масштабирование применяется после прорисовки окна.
DPI-Aware приложения
Чтобы избежать масштабирования, программа может пометить себя как поддерживающую DPI. Это говорит о том, что DWM не будет выполнять автоматическое масштабирование DPI. Все новые приложения должны быть спроектированы с учетом DPI, так как осведомленность о DPI улучшает внешний вид параметров пользовательского интерфейса при высоком уровне DPI.
Программа объявляет свое разрешение с учетом DPI через манифест приложения. Манифест — это просто XML-файл, ОПИСЫВАЮЩИЙ библиотеку DLL или приложение. Манифест обычно внедряется в исполняемый файл, хотя он может быть предоставлен в виде отдельного файла. манифест содержит такие сведения, как зависимости библиотек DLL, запрошенный уровень привилегий и версия Windows, для которой была разработана программа.
Чтобы объявить, что программа учитывает DPI, включите в манифест следующую информацию.
приведенный здесь список является только частичным манифестом, но Visual Studio компоновщик автоматически создает остальную часть манифеста. Чтобы включить в проект частичный манифест, выполните следующие действия в Visual Studio.
Пометив программу как учитывающую DPI, вы сообщаете DWM, что окно приложения не масштабируется. Теперь при создании окна 500 × 500 окно будет занимать 500 × 500 пикселей, независимо от значения DPI пользователя.
GDI и DPI
Рисование GDI измеряется в пикселях. Это означает, что если программа помечена как совместимая с DPI, и вы запрашиваете GDI для рисования прямоугольника 200 × 100, полученный прямоугольник будет состоять из 200 пикселей в ширину и 100 пикселей в высоту на экране. Однако размеры шрифтов GDI масштабируются до текущего значения DPI. Иными словами, если вы создадите шрифт 72, размер шрифта будет составлять 96 пикселей в 96 DPI, а 144 пикселей — в 144 DPI. Ниже приведен шрифт точки 72, отображаемый в 144 DPI с помощью GDI.
Если в приложении учитывается DPI и для рисования используется GDI, масштабировать все координаты рисования в соответствии с DPI.
Direct2D и DPI
Direct2D автоматически выполняет масштабирование в соответствии с параметром DPI. В Direct2D координаты измеряются в единицах, называемых аппаратно -независимыми пикселями (DIP). DIP определяется как 1 или 1/96 логического дюйма. В Direct2D все операции рисования задаются в DIP, а затем масштабируются до текущего параметра DPI.
Масштаб
Размер DIP
96
1 пиксель
120
1,25 пикселей
144
1,5 пикселей
Например, если значение DPI для пользователя равно 144 DPI, и вы запрашиваете Direct2D для прорисовки прямоугольника размером 200 × 100, прямоугольник будет состоять из 300 × 150 физических пикселей. кроме того, DirectWrite измеряет размеры шрифтов в dip, а не на точках. Чтобы создать шрифт размером 12 пунктов, укажите 16 DIP (12 точек = 1/6 логический дюйм = 96/6 DIP). Когда текст отображается на экране, Direct2D преобразует DIP в физические Пиксели. Преимуществом этой системы является то, что единицы измерения согласуются как для текста, так и для рисования, независимо от текущего значения DPI.
Преобразование физических пикселей в DIP
Преобразование из физических пикселей в DIP использует следующую формулу.
Ниже приведен альтернативный способ получения значения DPI, если вы не используете Direct2D:
Изменение размера целевого объекта прорисовки
Если размер окна изменяется, необходимо изменить размер целевого объекта рендеринга для соответствия. В большинстве случаев также потребуется обновить макет и перекрасить окно. Эти действия показаны в следующем коде.
Функция жетклиентрект получает новый размер клиентской области в физических пикселях (не DIP). Метод ID2D1HwndRenderTarget:: resize обновляет размер целевого объекта рендеринга, также заданный в пикселях. Функция инвалидатерект принудительно выполняет перерисовку, добавляя всю клиентскую область в область обновления окна. (См. раздел Рисование окнав модуле 1.)
По мере увеличения или уменьшения размера окна, как правило, необходимо повторно вычислить расположение рисуемых объектов. Например, в программе Circle необходимо обновить радиус и центральную точку:
Метод ID2D1RenderTarget:: resize возвращает размер целевого объекта отрисовки в DIP (не в пикселях), который является подходящим блоком для вычисления макета. Существует тесно связанный метод ID2D1RenderTarget:: жетпикселсизе, который возвращает размер в физических пикселях. Для целевого объекта прорисовки HWND это значение соответствует размеру, возвращенному жетклиентрект. Но помните, что рисование выполняется в DIP, а не в пикселях.
В этой части статьи речь пойдет о правилах масштабирования интерфейсов приложений в разных версиях 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, внедрение дисплеев с высокой плотностью пикселей и пр.
