DPI Unaware

DPI Unaware (рус. изначальный грех интерфейсного программирования, мыльная опера Билла Гейтса, феномен размытых окон) — благословенное состояние классического софта, разработчики которого в гробу видали ваши 4K-мониторы, Retina-дисплеи и прочие хипстерские извращения. Выражается в том, что программа упорно считает, будто на дворе стоит 1995 год, на столе у пользователя трудится пузатый ЭЛТ-монитор с разрешением 1024x768, а системный параметр плотности пикселей намертво зафиксирован на отметке в 96 DPI.

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

Откуда взялись 96 DPI

В конце 1980-х и начале 1990-х годов инженеры Microsoft, Apple и IBM пытались договориться, как соотносить картинку на экране с реальным физическим миром.

1. В физическом мире существует понятие типографского пункта. 1 пункт равен 1/72 дюйма.
2. Компания Apple решила пойти по пути физического реализма. В первых компьютерах Macintosh плотность пикселей составляла ровно 72 DPI. Таким образом, 1 пиксель на экране был равен ровно 1 типографскому пункту. Если вы верстали документ со шрифтом в 12 пунктов, на экране он занимал ровно 12 пикселей. Это было удобно для полиграфии, но при тогдашних размерах экранов заставляло пользователей утыкаться носом в ЭЛТ-трубки.
3. Компания Microsoft решила, что зрение пользователей важнее полиграфической точности. Они предположили, что типичный пользователь сидит дальше от экрана, поэтому интерфейс нужно сделать крупнее. Они взяли за основу стандартную плотность в 96 DPI. Таким образом, элементы интерфейса на экранах Windows 95 стали на 33 % крупнее, чем на Mac.

С этого момента цифра 96 стала священной коровой редмондской корпорации. Все классические графические библиотеки Windows (прежде всего, легендарный GDI) создавались с абсолютной уверенностью, что эта цифра высечена в камне на веки вечные.

Программисты быстро усвоили это правило и начали верстать интерфейсы в абсолютных пикселях. Формула была проста: если кнопка имеет размер 100 на 30 пикселей, она везде будет выглядеть отлично. И это работало. До тех пор, пока физический размер пикселя не начал стремительно уменьшаться.

Появление HiDPI

Лулзы начались, когда производители дисплеев научились упаковывать безумное количество пикселей в крошечные матрицы. Сначала на мобилках появилась Retina от Apple с плотностью более 300 DPI, а затем мода на высокое разрешение пришла и на персональные компьютеры.

Представьте ситуацию:

• У вас есть старый монитор с диагональю 24 дюйма и разрешением 1920x1080. Его плотность пикселей составляет примерно 92 DPI. Ваше старое любимое приложение выглядит на нём отлично. Кнопка размером 100 на 30 пикселей имеет физический размер примерно 2.7 на 0.8 сантиметра.
• Вы решаете сделать себе подарок и покупаете новенький монитор той же диагонали, но с разрешением 4K (3840x2160). Его плотность пикселей подскакивает до 184 DPI. Физический размер пикселя уменьшился ровно в 2 раза!
• Вы запускаете то же самое приложение. И о чудо! Кнопка размером 100 на 30 пикселей теперь имеет физический размер 1.3 на 0.4 сантиметра. Текст внутри неё превращается в линию муравьев, а чтобы нажать на неё мышкой, вам требуется точность профессионального киберспортсмена.

Если же запустить такое приложение на современном 13-дюймовом ноутбуке с разрешением 3200x1800 (около 280 DPI), интерфейс программы просто схлопывается в сингулярность. Кнопки становятся размером с игольное ушко, а текстовые поля превращаются в тонкие полоски, разобрать содержимое которых можно только с помощью электронного микроскопа.

Великий поход Microsoft по граблям

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

Эпоха Windows XP

1-й и самый примитивный костыль появился ещё в Windows XP. Идея была глупой и простой: давайте разрешим пользователю увеличивать системный шрифт (например, до 120 DPI или 125 %). При этом физический размер окон и элементов управления в пикселях оставался прежним.

Это привело к лавинообразному росту лулзов и матерных слов со стороны пользователей:

• Программисты, верставшие формы в Win32 или Delphi, задавали жесткие размеры кнопок в пикселях (например, ширина 80 пикселей).
• Шрифт увеличивался на 125 %.
• Текст кнопки типа Зарегистрироваться банально переставал влезать в физические границы кнопки. На экране это выглядело как великая стена сокращений: Зарегис… или Нажать д….
• Элементы управления накладывались друг на друга, подписи к полям ввода налезали на сами поля ввода, а часть кнопок просто уезжала за нижнюю границу окна, делая невозможным нажатие кнопки ОК или Применить.

Эпоха Windows Vista/7

Поняв, что доверять разработчикам софта нельзя, в Windows Vista внедрили технологию DPI Virtualization.

Суть костыля заключалась в тотальном обмане:

1. Если программа запускается в системе с масштабированием (например, 150 %) и при этом не имеет специальной пометки в манифесте, операционная система нагло врет ей при старте.
2. На все запросы программы типа Какое разрешение у экрана? или Какой сейчас системный DPI?, Windows 7 твердо и четко отвечает: 96 DPI, хозяин!.
3. Программа спокойно отрисовывает свой интерфейс в специальный невидимый буфер в старых добрых пикселях.
4. После этого оконный менеджер Windows — DWM — берет получившийся буфер как обычную картинку и тупо растягивает её с помощью видеокарты до реального физического размера на экране.

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

Поскольку растягивание происходило обычным билинейным фильтром, весь интерфейс программы превращался в жуткое мыльное месиво. Шрифты выглядели так, словно монитор протерли жирной тряпкой или облили вазелином. Особенно страдали пользователи на экранах с промежуточным масштабированием (типа 125 % или 150 %), где пиксели не могли быть пересчитаны 1 к 2.

Эпоха Windows 8/8.1

В Windows 8.1 Microsoft столкнулась с новой напастью — конфигурациями из нескольких мониторов с разной плотностью пикселей. Например, планшет Surface Pro с экраном высокого разрешения подключается к дешевому офисному монитору Full HD.

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

• Вы открываете приложение на экране планшета (масштаб 200 %). Картинка должна быть большой.
• Вы перетаскиваете окно приложения на внешний монитор (масштаб 100 %). Картинка должна мгновенно уменьшиться в 2 раза, иначе окно займет весь экран.

Для этого был разработан режим Per-Monitor DPI Awareness (V1). Программа должна была ловить системное сообщение WM_DPICHANGED, выковыривать из параметров новый масштаб и новый прямоугольник окна и самостоятельно пересчитывать все свои размеры.

Естественно, 99 % разработчиков этот механизм проигнорировали, так как писать ручной пересчет координат для каждого чиха — удовольствие крайне сомнительное. В результате приложения при перетаскивании между мониторами либо оставались гигантскими, либо превращались в мыльное месиво, растянутое силами ОС.

Эпоха Windows 10/11

В Windows 10 Creators Update (версия 1703) редмондские инженеры решили довести костылестроение до абсолюта, представив режим Per-Monitor V2 (PMv2).

В этом режиме операционная система берет на себя максимум грязной работы:

• Автоматически масштабирует неклиентскую область окна (заголовок, рамки, системные кнопки закрытия и сворачивания).
• Автоматически масштабирует стандартные диалоговые окна Win32 (созданные через CreateDialog).
• Автоматически перерисовывает стандартные элементы управления (чекбоксы, радиокнопки, полосы прокрутки) с использованием растровых ресурсов нужного масштаба.
• Рассылает уведомления об изменении DPI дочерним окнам в Windows 11.

Этот режим действительно облегчил жизнь разработчикам, но только тем, кто использовал стандартные системные элементы управления. Те же, кто рисовал свои интерфейсы самостоятельно (игры, графические редакторы, кастомные плееры), остались наедине со своими пиксельными проблемами.

Для совсем безнадёжного старья, написанного на чистом GDI, завезли фичу GDI Scaling. Система пытается перехватывать векторные команды отрисовки GDI и выполнять их сразу в повышенном разрешении. Текст становится чётким, но этот метод ломает работу с кастомными битмапами (DIB) и часто приводит к артефактам отрисовки, обрезанию букв и странному поведению курсора мыши.

Паноптикум графических фреймворков

Каждая графическая библиотека справляется с проблемой DPI в силу своей испорченности, генерируя тонны боли и лулзов для разработчиков.

Win32 API

Старый добрый Win32 API и библиотека GDI — это настоящий музей цифровой археологии. Здесь нет никакого автоматического масштабирования в принципе. Если вы пишите код на чистом C++ под Win32, вы обязаны рассчитывать каждый пиксель вручную.

Чтобы сделать приложение хотя бы минимально адаптируемым, программистам приходится использовать классический костыль в виде функции MulDiv (умножить и разделить с округлением):

Начиная с Windows 10 1607, код пересчета выглядит так:

int currentDpi = GetDpiForWindow(parentWnd);
int scaledX = MulDiv(x, currentDpi, 96);
int scaledY = MulDiv(y, currentDpi, 96);
int scaledWidth = MulDiv(width, currentDpi, 96);
int scaledHeight = MulDiv(height, currentDpi, 96);

Если вы забыли пересчитать хотя бы 1 координату или размер шрифта — ваш интерфейс гарантированно поплывет. Прибавьте к этому необходимость перезагружать растровые картинки (иконки, текстуры кнопок) под каждый уровень масштаба (100 %, 125 %, 150 %, 200 %), иначе они превратятся в размытую кашу. Неудивительно, что разработчики софта предпочитают заявить свое приложение как DPI Unaware и отдать его на растерзание системному мыловару Windows, лишь бы не заниматься этой математикой.

Windows Forms

WinForms из состава .NET Framework — это, пожалуй, главный источник боли и ночных кошмаров для корпоративных разработчиков. Он создавался как простая обертка над Win32 элементами управления и унаследовал от них абсолютно все проблемы с позиционированием.

WinForms пытается масштабировать интерфейс автоматически, используя свойства AutoScaleMode и AutoScaleDimensions.

Но в реальности это превращается в генератор случайных макетов:

• Если разработчик создал форму на мониторе с масштабом 100 % (96 DPI), а пользователь запустил её на ноутбуке с масштабом 125 % (120 DPI), WinForms пытается пропорционально увеличить размеры элементов и шрифтов.
• Но поскольку шрифты масштабируются нелинейно (высота символов увеличивается быстрее, чем ширина), текст начинает вылезать за границы кнопок и текстовых полей.
• Если на форме используются контейнеры типа FlowLayoutPanel или TableLayoutPanel, элементы внутри них начинают накладываться друг на друга, сжиматься в 0-й размер или улетать за видимые границы экрана.
• Использование привязок Anchor (например, привязка кнопки к нижнему правому углу) в сочетании с автоматическим масштабированием приводит к тому, что элементы управления улетают в бесконечность, оставляя огромные пустые пространства.

Дополнительный лулз заключается в процессе разработки. Если программист открывает визуальный дизайнер Visual Studio на мониторе с масштабом, отличным от 100 %:

1. Visual Studio честно пытается отрендерить форму в текущем масштабе.
2. При сохранении формы дизайнер автоматически перезаписывает сгенерированный код в файле Designer.cs, подставляя туда жестко закодированные пиксельные координаты, пересчитанные под текущий DPI разработчика.
3. Когда этот проект открывает его коллега, у которого на мониторе стоит 100 % DPI, он видит абсолютно изуродованную верстку.

Именно поэтому современная Visual Studio при запуске на экранах с масштабированием вежливо, но настойчиво вывешивает плашку: Для работы с дизайнером рекомендуется перезапустить Visual Studio в режиме без поддержки DPI (DPI Unaware).

WPF

WPF рекламировался как революционная замена WinForms. В WPF все координаты задаются не в физических пикселях, а в логических единицах (Device-Independent Pixels, DIP), где 1 логический пиксель равен 1/96 дюйма. Движок WPF работает на основе DirectX и теоретически должен идеально и плавно масштабировать интерфейс до любого размера.

Но суровая реальность быстро обломала крылья векторным мечтателям:

• Поскольку логические координаты могут быть дробными, векторный рендерер WPF часто пытается отрисовать линию толщиной в 1 логический пиксель ровно посередине между физическими пикселями монитора. В результате субпиксельное сглаживание ClearType превращает тонкую и чёткую черную линию в размытую серую полосу шириной в 2 физических пикселя. Текст выглядит грязным и нечётким. Чтобы бороться с этим, разработчикам приходится усыпать XAML-код свойствами SnapsToDevicePixels="True" и UseLayoutRounding="True", заставляя движок принудительно округлять координаты до физических пикселей экрана.
• Обычные растровые иконки (`.png` или `.ico`) без специальной настройки нещадно мылятся при любом масштабе, отличном от 100 %. Разработчикам приходится либо использовать гигантские растровые изображения с включенными мипмапами, либо переходить на тяжеловесную отрисовку векторных иконок через Path-геометрию в XAML.
• По умолчанию WPF-приложения компилируются с поддержкой только системного DPI (System DPI Aware). Это значит, что если пользователь перетащит окно WPF-приложения на второй монитор с другим масштабом, Windows применит к нему банальную растровую растяжку, превратив хваленый векторный интерфейс в мыльное месиво. Для включения полноценного Per-Monitor V2 режима приходится ковырять манифесты проекта и писать сложный обвязочный код.

CEF/Electron/Chromium

Современные десктопные приложения часто представляют собой гибрид ужа с ежом — старое классическое приложение (например, на Delphi) встраивает внутрь себя Chromium Embedded Framework (CEF) или использует Electron (как Discord, VSCode) для отображения веб-контента. И здесь проблема DPI расцветает самыми яркими красками.

Представьте ситуацию:

• У вас есть старое Delphi-приложение, помеченное в манифесте как DPI Unaware. Операционная система запускает его в режиме виртуализации, рассчитывая на 96 DPI, а затем растягивает готовое окно как картинку.
• Внутри этого приложения создается встроенный браузер Chromium. Chromium по умолчанию является чрезвычайно продвинутым и современным зверем — он всегда работает в режиме Per-Monitor DPI Aware.
• Chromium видит реальный физический масштаб экрана (например, 200 %) и отрисовывает веб-страницу с идеальной четкостью под этот масштаб.
• Но хост-приложение на Delphi считает, что масштаб равен 100 %. Оно выделяет под браузер область размером, скажем, 800 на 600 логических пикселей.
• Chromium пытается впихнуть туда контент, отрисованный под 200 % масштаб.
• В результате веб-страница либо отображается в гигантском размере, не влезая в окно, либо мылится и сжимается обратно силами Windows.
• Но самый главный лулз — это координаты мыши. Delphi-приложение передает клики мыши по координатам виртуального экрана (например, клик в точке 400x300). Браузер же ожидает координаты в физических пикселях (800x600). В итоге пользователь кликает по кнопке на веб-странице, а клик улетает совершенно в другое место экрана.

Чтобы подружить эти 2 разные эпохи программирования, разработчикам приходится использовать безумные костыли вроде принудительной установки масштаба устройства в Chromium через параметры запуска:

Panel1.ForcedDeviceScaleFactor := 1.5; // Насильно заставляем браузер использовать масштаб

Или полностью отключать поддержку DPI в самом Chromium, превращая современный веб-движок в унылое мыльное нечто, лишь бы координаты мыши совпадали с визуальным отображением элементов.

1С:Предприятие

Платформа 1С:Предприятие — это еще 1 легендарный монумент отечественного софтостроения. На операционных системах Windows масштабирование 1С работает сносно (благодаря встроенным костылям совместимости Microsoft), но когда дело доходит до Linux, начинается настоящий хардкор.

Современные дистрибутивы Linux (например, Deepin Linux, позиционируемый как красивая и удобная замена Windows для госучреждений) часто запускаются на рабочих местах с мониторами высокого разрешения (4K). По умолчанию 1С под Linux ведет себя как классическое DPI Unaware приложение — оно просто игнорирует системные настройки масштабирования рабочего стола.

Если запустить 1С на 4K-мониторе без дополнительных телодвижений:

• Все шрифты, списки документов, кнопки и меню становятся микроскопическими. Работа бухгалтера превращается в пытку.
• Если попытаться изменить DPI системных шрифтов в настройках Linux (например, выставить 120 DPI вместо 96 DPI), шрифты увеличиваются, но размеры самих элементов управления и окон остаются старыми! Текст начинает обрезаться, перекрывать друг друга, а кнопки превращаются в месиво из букв.

Решается эта проблема исключительно через ручное прописывание переменных окружения GTK перед запуском тонкого или толстого клиента 1С. Системные администраторы массово создают специальные bash-скрипты запуска:

# Задаем жесткое целочисленное масштабирование интерфейса в 3 раза
# и одновременно уменьшаем масштаб шрифтов в 2 раза для компенсации перекосов
GDK_SCALE=3 GDK_DPI_SCALE=0.5 /opt/1C/v8.3/x86_64/1cv8s

Этот костыль позволяет элементам интерфейса увеличиться до читаемых размеров, но порождает новые проблемы — интерфейс становится слишком огромным, так как переменная GDK_SCALE принимает только целые значения (нельзя выставить масштаб 1.5 или 1.25). В итоге пользователю приходится выбирать: либо ломать глаза об микроскопический интерфейс, либо созерцать огромные кнопки размером в 1/4 экрана.

Игровые движки

В мире разработки 3D-приложений и игр проблема DPI приобретает поистине мистический характер. Разработчикам приходится постоянно балансировать между физическими пикселями экрана (в которых работает видеокарта при рендере 3D-сцены) и логическими единицами (в которых верстается игровой интерфейс).

Например, в движке UNIGINE существует четкое разделение систем координат:

• Глобальные координаты окон и курсора мыши определяются строго в физических пикселях относительно левого верхнего угла главного экрана. Это необходимо для точного позиционирования окон на многомониторных конфигурациях.
• Размеры окон, клиентских областей и виджетов GUI по умолчанию задаются в логических единицах (Units).
• If на экране установлен масштаб 150 %, то 1 логическая единица равна 1.5 физическим пикселям.

Если программист решит пренебречь этим разделением и попытается использовать сырые координаты мыши для взаимодействия с игровым интерфейсом (например, для проверки попадания клика в кнопку):

// Трагический быдлокод для проверки клика
ivec2 mouse_pos = Input::getMousePosition(); // Координаты в физических пикселях
ivec2 widget_size = my_widget->getClientSize(); // Размер в логических единицах
if (mouse_pos.x > widget_size.x) { /* Клик улетит мимо кнопки на масштабе > 100%! */ }

Чтобы избежать подобных казусов, разработчикам приходится постоянно использовать специальные функции конвертации координат туда и обратно:

// Правильный пересчет координат с учетом текущего DPI
ivec2 physical_widget_size = window->toRenderSize(my_widget->getClientSize());

Если этого не делать, игровой интерфейс на экранах высокой плотности начнет вести себя неадекватно: зоны клика уедут в сторону от нарисованных кнопок, прокрутка списков будет срабатывать раньше времени, а элементы интерфейса будут накладываться на 3D-картинку с жуткими искажениями.

Альтернативные миры

Пока пользователи Windows продолжают плакать, колоться и жрать кактус, в других операционных системах к проблеме DPI подошли с совершенно другими философскими концепциями.

macOS

В дискуссиях о масштабировании часто звучит резонный вопрос: Почему на компьютерах Mac всё работает идеально, а на Windows и Linux пользователи вынуждены годами жрать кактус?.

Секрет успеха Apple кроется в 2-х вещах — тотальном контроле над аппаратным обеспечением и жестком игнорировании обратной совместимости.

Когда в 2012 году Apple представила 1-й MacBook Pro с экраном Retina, они не пытались сохранить совместимость с приложениями из эпохи Mac OS 9:

• Они объявили, что плотность пикселей новых экранов увеличивается ровно в 2 раза. Не в 1.25, не в 1.5, а строго в 2.0 раза.
• Вся система координат macOS была переведена с физических пикселей на логические точки (Points). При масштабе 200 % 1 логическая точка идеально укладывается в квадрат из 4 физических пикселей (2 на 2). Никаких округлений координат, никакого размытия на границах элементов, шрифты выглядят великолепно.
• Разработчикам софта было прямо сказано: Либо вы добавляете в ресурсы своих программ векторные иконки и картинки высокого разрешения с суффиксом @2x, либо ваше приложение будет выглядеть на новых экранах как уродливое пиксельное недоразумение из прошлого века.
• Через несколько лет Apple просто прекратила поддержку 32-битных приложений и старых графических API Carbon, окончательно вырезав из системы любой намек на обратную совместимость. Хочешь работать на Mac — переписывай всё под современные стандарты Cocoa и Metal.

Благодаря этому целочисленному авторитаризму, macOS не знает проблем с размытыми шрифтами при масштабе 200 %. Если же пользователю требуется промежуточный масштаб, macOS рендерит весь рабочий стол в гигантском разрешении (например, под масштаб 200 % от повышенного разрешения), а затем аппаратно сжимает картинку на выходе видеокарты. Но благодаря огромной плотности пикселей на фирменных экранах Apple (обычно более 220 DPI), получившееся микроскопическое размытие человеческий глаз просто не способен заметить.

Linux

В мире Linux сейчас происходит великий исторический переход со старого графического сервера X11 на новый протокол Wayland. И тема масштабирования интерфейсов является 1-м из главных полей сражений в этой священной войне.

Почему X11 должен умереть

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

Если у вас подключено 2 монитора с разной плотностью пикселей:

• X11 видит их как 1 огромный общий виртуальный рабочий стол.
• Системный параметр DPI (задаваемый через Xft.dpi) может быть только 1 на весь этот виртуальный стол.
• Если вы выставите масштаб под 4K-монитор (например, 192 DPI), то на 2-м мониторе Full HD все элементы интерфейса увеличатся в 2 раза и станут просто гигантскими.
• Если вы выставите масштаб под Full HD монитор (96 DPI), то на 4K-мониторе всё сожмется в микроскопическую кашу.

Никаких штатных способов решить эту проблему на уровне сервера X11 не существует. Все существующие костыли (вроде ручного пересчета размеров в GTK и Qt) работают нестабильно и регулярно приводят к зависаниям и падению графической оболочки.

Wayland

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

Архитектура Wayland изначально поддерживает только целочисленное масштабирование (Scale Factor = 1, 2, 3 и так далее):

• Если у вас 4K-монитор, Wayland просто выставляет для него масштаб 2. Приложение отрисовывает интерфейс в разрешении в 2 раза больше стандартного, и картинка выглядит идеально четкой.
• Но что делать, если масштаб 200 % для вас слишком велик (всё выглядит огромным), а при масштабе 100 % всё слишком мелкое? Вам нужен промежуточный масштаб 125 % или 150 %.

Для реализации дробного масштабирования (Fractional Scaling) разработчики Wayland (в частности, создатели рабочего стола GNOME) внедрили схему, которую в народе ласково называют целочисленным фашизмом:

1. Если пользователь выбирает масштаб 150 %, система заставляет приложение отрендерить свой интерфейс в масштабе 200 % (то есть в 2 раза больше).
2. Затем получившаяся огромная растровая картинка окна сжимается силами видеокарты до 150 %.

Этот подход порождает волну негодования:

• Чтобы показать простое текстовое окно в масштабе 150 % на 4K-экране, видеокарта должна сначала отрендерить его в сумасшедшем разрешении 5K или 6K, а затем непрерывно выполнять операцию даунскейлинга. На ноутбуках со встроенной графикой это приводит к мгновенному разогреву процессора и быстрому разряду батареи.
• Любое некратное сжатие растровой картинки неизбежно приводит к размытию пикселей. В итоге кристально четкие векторные шрифты, ради которых и покупался дорогой 4K-монитор, превращаются в грязное, слегка размытое месиво. Пользователь получает ровно то же самое качество картинки, как если бы он просто снизил разрешение своего монитора в настройках до Full HD, но при этом его компьютер работает на пределе возможностей.

XWayland

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

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

Инструкция по выживанию в 2026 году

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

Как спасти свои глаза

1. Используйте режим System (Enhanced): В свойствах ярлыка проблемной программы на вкладке Совместимость найдите настройки DPI. Попробуйте переключить масштабирование в режим Система (дополнительно) — в оригинале System (Enhanced). Это заставит Windows применить алгоритмы GDI Scaling. Текст станет гораздо чётче, хотя иконки могут слегка размыться.
2. Забудьте про дробное масштабирование: Если есть возможность, избегайте масштабов типа 125 % или 175 %. Самые стабильные и предсказуемые режимы для Windows и Linux — это 100 % (без масштабирования), 200 % (четкое удвоение пикселей) и 300 %. При целочисленном масштабировании операционным системам гораздо проще пересчитывать сетку интерфейса без округлений и размытия.
3. Не верстайте формы на экранах с масштабом: Если вы программист на WinForms или Delphi — никогда, слышите, никогда не занимайтесь визуальным проектированием интерфейсов на мониторе с масштабом, отличным от 100 %. Держите для этих целей старый добрый Full HD монитор или принудительно запускайте среду разработки с флагом `/highdpi:unaware`. Ваши коллеги и пользователи скажут вам спасибо.
4. Переходите на векторные иконки: Если вы создаёте интерфейс — забудьте про растровые `.bmp` и `.png` картинки фиксированного размера для элементов управления. Используйте SVG, шрифтовые иконки (типа FontAwesome) или пишите код отрисовки графики через векторные примитивы. Это единственный способ заставить приложение выглядеть прилично на экранах 2026 года и далее.

Твики реестра

Если вы работаете системным администратором и ваши пользователи постоянно жалуются на то, что при подключении через удаленный рабочий стол (RDP) старая ERP-система или 1С выглядит размытой или у нее уезжают кнопки:

Вы можете принудительно заставить терминальный сервер игнорировать масштаб экрана клиента, установив специальный параметр в реестре сервера. Для этого создайте `.reg` файл со следующим содержимым:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations]
"IgnoreClientDesktopScaleFactor"=dword:00000001

После этого все RDP-сессии будут запускаться со строгим масштабом 100 %, независимо от того, какой масштаб установлен у пользователя на локальном компьютере. Да, на 4K-экране удаленное окно станет маленьким, но зато оно будет идеально чётким, а верстка интерфейса старой программы гарантированно не уедет за пределы видимости.

	Мелкий шрифт и слабое зрение — это давняя проблема взаимодействия человека и компьютера. Решать её пытались в разное время, разные люди, разными способами.
— Разработчики 1С, плача над интерфейсом Такси