Размытие шрифтов WPF-Решения

Техническое образование

Существует глубокая статья о WPF Text render от одного из менеджеров текстовых программ WPF на windowsclient.net: Text Clarity в WPF .

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

Разница очевидна, если сравнивать classический «каскадный» шаблон. WinForms в нижней левой части, WPF в верхней правой части:

Хотя я и не поклонник особенностей визуализации шрифтов WPF, я могу представить себе шум, если анимация будет прыгать так же, как в каскаде Winforms.

Игра с реестром

Особый интерес для меня вызвала ссылка на статью MSDN « Параметры реестра ClearType », которая объясняет возможные корректировки пользовательской стороны в реестре:

• Уровень ClearType: количество подпиксельных намеков
• Уровень гаммы
• Структура пикселей: как расположены цветовые полосы в пикселе дисплея
• Уровень контрастности текста: регулирует ширину стеблей глифов, чтобы сделать шрифт более тяжелым

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

Другой подход

Лучшим советом, который дает статья Text Clarity, является увеличение размера шрифта и изменение шрифта. Calibri работает для меня лучше, чем стандартный пользовательский интерфейс Segoe. Из-за его популярности в качестве веб-шрифта, я тоже пробовал Verdana, но он имеет неприятный прыжок в весе между 14pt и 15pt, что очень заметно при анимации размера шрифта.

WPF 4.0

WPF 4 будет иметь улучшенную поддержку для оказания влияния на предоставление шрифтов. Есть статья в текстовом блоге WPF, объясняющая изменения. Наиболее заметно, что есть (по крайней мере) три разных вида рендеринга текста:

_{Для каждого дизайнера должно быть достаточно веревки.}

.NET 4, наконец, имеет решение плохого качества рендеринга WPF, но оно хорошо скрыто. Установите для каждого windows следующее:

TextOptions.TextFormattingMode="Display" 

Значение по умолчанию – «Идеальное», что совсем не так, как следует из названия.

В TextOptions есть еще два варианта: TextHintingMode и TextRenderingMode, но оба они имеют разумные значения по умолчанию.

Я столкнулся с проблемой на днях, когда я использовал границу, на которой был применен DropShadowEffect . В результате весь текст внутри этой границы был чрезвычайно размытым. Не имеет значения, был ли текст внутри других панелей или непосредственно под границей – любой текстовый блок, который является дочерним по отношению к родительскому объекту, у которого есть Эффект, кажется, затронут.

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

Вот так:

Это будет исправлено в VS2010 (и WPF4) бета 2:

SnapToDevicePixels применяется только к формам WPF (строки и т. Д.), А не к текстовому рендерингу.

В этом вопросе не существует обходного пути. По словам Microsoft, поведение «по дизайну».

Также ознакомьтесь с этой веткой на форумах Microsoft, где обсуждаются проблемы – у нее появилось несколько ответов от реселлеров MS, которые уточняют их позицию по этой проблеме.

С точки зрения разработчика единственным известным «обходным решением» на сегодняшний день является использование classа GDI + и / или Windows Forms TextRenderer для рендеринга текста в bitmap, а затем визуализации этого растрового изображения в качестве элемента управления WPF. Помимо очевидных последствий для работы, это не облегчает проблему для существующих приложений.

Теперь я создал билет Microsoft Connect для этой проблемы (к моему удивлению, несмотря на всю негативность, в указанном трекере не было реального отчета об ошибках).

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

Просто попробовал VS2010 beta, который все делается в WPF, и он страдает BADLY от проблемы с размытым шрифтом. Особенно на всплывающих подсказках.

Это, по-видимому, дает некоторые доказательства того, что WPF4 на самом деле не решит проблему (если что-то еще хуже)

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

Эти настройки реестра (в десятичной системе) работали на меня и приближались к моему обычному шрифту cleartype:

• ClearTypeLevel: 10 (в основном, сглаживание в оттенках серого)
• GammaLevel: 1300 (более высокая гамма сделала шрифт слишком тонким, и я видел цвета в псевдониме)

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

 TextOptions.TextRenderingMode TextOptions.TextFormattingMode RenderOptions.ClearTypeHint 

SnapToDevicePixels не делает различий в текстовом рендеринге.

Я предпочитаю:

 TextOptions.TextRenderingMode="Auto" TextOptions.TextFormattingMode="Ideal" RenderOptions.ClearTypeHint="Auto" 

где вертикальные линии никогда не размываются.

Используемый шрифт – Open Sans Light, который может быть действительно прекрасным, если он хорошо используется, как в последнем TeamViewer.

Для тех, кто использует Mahapps.Metro, проблема заключается в TransitioningContentControl https://github.com/MahApps/MahApps.Metro/issues/889

Говорят, что «SnapToDevicePixels = true» работает, но я никогда не видел хороших результатов.

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

Очевидно, это не решение проблемы, но я так и работал над этим.