Problème de polices WPF Blurry - Solutions


153

Le problème est décrit et démontré sur les liens suivants:

Explication: Clarté du texte dans WPF . Ce lien a une comparaison de polices.

Je voudrais rassembler toutes les solutions possibles à ce problème. Microsoft Expression Blend utilise WPF mais les polices semblent lisibles.

  • Fond sombre comme dans Microsoft Expression Blend
  • Augmentation de la taille de la police et modification de la police (Calibri ...) [lien]
  • Incorporer les formulaires Windows [lien]
  • Utilisez la classe TextRenderer GDI + et / ou Windows Forms pour restituer le texte en bitmap, puis restituer ce bitmap en tant que contrôle WPF. [lien]

Y a-t-il d'autres solutions?

Cela va être corrigé dans VS2010 (et WPF4) beta 2

C'EST COMME QU'IL A ÉTÉ FINALEMENT RÉSOLU!

ComputerZen.com de Scott Hanselman: WPF et flou du texte, maintenant avec une clarté totale


VS2010RC est totalement inutilisable pour moi mpdreamz.nl/vs2010RC-blur.png
Martijn Laarman

VS2010RC sur ma machine est beaucoup mieux que sur votre photo, en fait avec un fond blanc est très bon mais craint toujours avec un fond sombre.
Robert Vuković

Avez-vous trouvé une solution à ce problème, en fait, j'ai le même problème ici dans mon application et j'utilise WPF 3.5 avec VS2010
SharpUrBrain

Les 3 derniers liens sont morts.
SHIN JaeGuk

Réponses:


107

Contexte technique

Il existe un article détaillé sur le rendu de texte WPF de l'un des gestionnaires de programme de texte WPF sur windowsclient.net: Clarté du texte dans WPF .

Le problème se résume au fait que WPF a besoin d'un rendu de police à mise à l'échelle linéaire pour des animations fluides. Pure ClearType, en revanche, prend un peu de liberté avec la police pour pousser les tiges verticales dans le pixel suivant.

La différence est évidente si l'on compare le modèle classique de "cascade". WinForms sur le côté inférieur gauche, WPF sur le côté supérieur droit:

Bien que je ne sois pas non plus fan des idiosyncrasies de rendu des polices de WPF, je peux imaginer le bruit si les animations sautaient comme elles le font dans la cascade Winforms.

Jouer avec le registre

Le lien vers l'article MSDN " ClearType Registry Settings ", qui explique les ajustements possibles côté utilisateur dans le registre, m'a particulièrement intéressé :

  • Niveau ClearType: quantité d'indices de sous-pixels
  • Niveau gamma
  • Structure des pixels: comment les bandes de couleur dans un pixel d'affichage sont organisées
  • Niveau de contraste du texte: ajuste la largeur des tiges de glyphe pour alourdir la police

Jouer avec ces paramètres n'a pas vraiment amélioré le problème sous-jacent, mais peut aider en réduisant l'effet de saignement de couleur pour les utilisateurs sensibles.

Une autre approche

Le meilleur conseil donné par l'article sur la clarté du texte était d'augmenter la taille de la police et de changer la police. Calibri fonctionne mieux pour moi que l'interface utilisateur Segoe standard. En raison de sa popularité en tant que police Web, j'ai également essayé Verdana, mais son poids entre 14pt et 15pt est très visible lors de l'animation de la taille de la police.

WPF 4.0

WPF 4 aura une meilleure prise en charge pour influencer le rendu des polices. Il existe un article sur le blog de texte WPF expliquant les modifications. Plus important encore, il existe maintenant (au moins) trois types différents de rendu de texte:

comparaison de rendu de texte

<grumble> Cela devrait être assez de corde pour chaque concepteur. </grumble>


11
excellente explication, +1. Cela explique probablement pourquoi Flash a également un rendu de polices aussi horrible.
Jeff Atwood

1
Oui. C'est une bonne explication, mais j'aimerais toujours qu'il y ait un moyen d'activer les indices de police pour un joli look lorsque vous savez que vous n'allez pas animer. Je suppose que cela impliquerait une échelle donnée pour laquelle vous optimisez l'indication. Ce genre de choses fait que WPF me semble encore une version bêta.
PeterAllenWebb

Ce n'est pas comme si la variante "évolutive" n'utilisait pas d'indication de police, c'est juste que WPF n'optimise pas pour atteindre la grille de pixels, comme le fait ClearType. On peut soutenir que SnapToDevicePixels devrait fonctionner pour le texte, mais cela devrait toujours être hérité car un contrôle ne peut pas savoir s'il peut se casser ou non.
David Schmitt

2
La propriété jointe TextOptions.TextFormattingMode ( msdn.microsoft.com/en-us/library/ee169597.aspx ) est particulièrement pertinente . WPF4 et Silverlight ont également les propriétés UseLayoutRounding ( msdn.microsoft.com/en-us/library/dd783605.aspx ) et SnapsToDevicePixels ( msdn.microsoft.com/en-us/library/… ).
Pat

@All: Je ne trouve pas de moyen de désactiver l'anti-aliasing du texte dans WPF3.5 et par conséquent, l'étiquette ou le texte du bouton semble vraiment mauvais. Idéalement, je voudrais désactiver l'anti-aliasing globalement pour les polices. Comment puis-je accomplir cela?
SharpUrBrain

128

.NET 4 a enfin une solution à la mauvaise qualité de rendu du texte de WPF, mais il est bien caché. Définissez les éléments suivants pour chaque fenêtre:

TextOptions.TextFormattingMode="Display"

La valeur par défaut est "Idéal" ce qui n'est pas du tout ce que le nom implique.

Il existe deux autres options dans TextOptions, à savoir TextHintingMode et TextRenderingMode, mais elles ont toutes deux des valeurs par défaut sensibles.


Tout. Merci. Cela m'aide à résoudre le problème, mais il vous suffit de le définir une fois dans le conteneur comme <grid>
Peter Du

Oui, et si vous le définissez sur une fenêtre, il est valable pour tout ce qui est contenu dans cette fenêtre.
Helge Klein

J'ai passé beaucoup de temps à chercher cela, sur des tonnes de sites et de blogs, qui ne cessent de dire à quel point le formatage du texte est meilleur dans VS2010 RTM / .Net 4 (je suis d'accord, ça l'est!). Mais aucun d'entre eux ne s'est soucié de mentionner comment vous pourriez faire en sorte que les applications WPF que vous construisez avec lui soient aussi belles. Pourquoi cette propriété est-elle si bien cachée? Merci beaucoup.
M-Peror

5
Tout ce que je veux, c'est ça! Je me fiche de la sophistication du rendu WPF, les polices sont tout simplement inacceptables pour quiconque.
Jerry Liang

1
"Idéal" fonctionne pour moi, au lieu de "Display". Le projet est sur .NET 4.6.2. Peut-être qu'ils ont corrigé le nom confus.
joe

40

J'ai rencontré un problème l'autre jour lorsque j'ai utilisé une bordure qui avait un DropShadowEffect appliqué. Le résultat était que tout le texte à l'intérieur de cette bordure était extrêmement flou. Peu importe si le texte était à l'intérieur d'autres panneaux ou directement sous la bordure - tout bloc de texte enfant du parent ayant un effet appliqué semble être affecté.

La solution à ce cas particulier était de ne pas mettre de choses à l'intérieur de la bordure qui a des effets, mais d'utiliser à la place une grille (ou tout autre élément prenant en charge la mise en place de contenu l'un sur l'autre) et de placer un rectangle dans la même cellule que le texte (c'est-à-dire en tant que frère ou sœur dans l'arbre visuel) et mettez-y les effets.

Ainsi:

<!-- don't do this --->
<Border>
     <Border.Effect>
          <DropShadowEffect BlurRadius="25" ShadowDepth="0" Opacity="1"/>
     </Border.Effect>
     <TextBlock Text="This Text Will Be Blurry" />
</Border>

<!-- Do this instead -->
<Grid>
  <Rectangle>
     <Rectangle.Effect>
          <DropShadowEffect BlurRadius="25" ShadowDepth="0" Opacity="1"/>
     </Rectangle.Effect>
  </Rectangle>
  <TextBlock Text="This Text Will Be Crisp and Clear" />
</Grid>

Cela a bien fait l'affaire. Un peu de hack, mais mieux que de déconner avec les paramètres, etc. Merci. Une chose que je devais faire cependant, était de définir le remplissage du rectangle sur quelque chose. C'était peut-être juste ma configuration.
HAdes

Ouais, vous avez raison ... le rectangle est par défaut transparent, ce qui rend l'ombre portée bizarre.
Isak Savo

cela ne se produit pas dans mon exemple d'application, j'utilise WPF 3.5
SharpUrBrain

@SharpUrBrain: que ne se passe-t-il pas? Est-ce toujours flou même après avoir utilisé mon deuxième exemple?
Isak Savo le

Oui, il est toujours flou après avoir utilisé votre deuxième exemple également
SharpUrBrain

10

Cela va être corrigé dans VS2010 (et WPF4) beta 2:


1
+1 pour les tests. Intéressant de voir à quel point ce texte est plus large.
David Schmitt

6

SnapToDevicePixels s'applique uniquement aux formes WPF (lignes, etc.), pas au rendu de texte.

Il n'existe aucune solution de contournement connue à ce problème. Selon Microsoft, le comportement est «par conception».

Voir également ce fil sur les forums Microsoft discutant des problèmes - il a reçu quelques réponses de MS qui clarifient leur position sur le problème.


Corrigé dans WPF 4 à l'aide de la propriété jointe TextOptions.TextFormattingMode ( msdn.microsoft.com/en-us/library/ee169597.aspx ).
Pat

1
Le nom de la propriété est "SnapsToDevicePixels" et non "SnapToDevicePixels" tel qu'il est écrit.
Nir Kornfeld

6

Du point de vue d'un développeur, la seule «solution de contournement» connue à ce jour consiste à utiliser la classe GDI + et / ou Windows Forms TextRenderer pour restituer le texte en une image bitmap, puis à restituer cette image bitmap en tant que contrôle WPF. Outre les implications évidentes sur les performances, cela ne résout pas le problème des applications existantes.

J'ai maintenant créé un ticket Microsoft Connect pour ce problème (à ma grande surprise, malgré toute la négativité, il n'y avait pas de rapport de bogue réel dans le tracker désigné).

Étant donné que c'est l'un des canaux officiels de communication des demandes et des questions à Microsoft, je vous conseillerais également de le parcourir pour une réponse plus rapide. Au moins, si vous souhaitez que le problème soit résolu d'une manière ou d'une autre, voter pour ce ticket là-bas et / ou valider le problème aidera à attirer l'attention des PM et des ingénieurs de Microsoft sur ce problème, et éventuellement à augmenter sa priorité perçue.


6

Je ne vois pas cela comme un bug, mais la configuration par défaut est en effet très ennuyeuse. Voici une comparaison de toutes les combinaisons de

TextOptions.TextRenderingMode
TextOptions.TextFormattingMode
RenderOptions.ClearTypeHint

SnapToDevicePixels ne fait aucune différence dans le rendu du texte.

http://i.stack.imgur.com/cS3S2.png

Je préfère:

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

où les lignes verticales ne sont jamais floues.

La police utilisée est Open Sans Light, qui peut être vraiment belle si elle est bien utilisée, comme dans le dernier TeamViewer.

Pour ceux qui utilisent Mahapps.Metro, le problème est le TransitioningContentControl https://github.com/MahApps/MahApps.Metro/issues/889


4

Je viens d'essayer la version bêta de VS2010, qui est tout fait dans WPF, et il souffre BADEMENT du problème de la police floue. Surtout sur les info-bulles.

Cela semble donner des preuves que WPF4 ne résoudra en fait pas le problème (si quelque chose semble pire)


3
Je dépose des bogues contre VS2010B1 pour chaque endroit de l'interface utilisateur, le texte est flou. Les info-bulles sont presque comiquement mauvaises, je suis d'accord. Compte tenu de la façon dont il a été explicitement dit que cela devait être corrigé dans WPF4, je ne peux qu'espérer que cela n'a tout simplement pas fait la coupe pour cette version bêta.
Will Dean

4

Wow, je ne peux pas croire que mes polices WPF soient enfin lisibles. Et je ne peux pas non plus croire qu'il n'y ait pas de boîte de dialogue d'options pour faciliter ces changements alors que les valeurs par défaut sont horribles sur mon écran.

Ces paramètres de registre (en décimal) ont fonctionné pour moi et se rapprochent le plus de ma police cleartype habituelle:

  • ClearTypeLevel: 10 (alias principalement en niveaux de gris)
  • GammaLevel: 1300 (un gamma plus élevé rendait la police trop fine et je voyais les couleurs dans l'aliasing)

3

Ils disent que "SnapToDevicePixels = true" fonctionne, mais je n'ai jamais vu de bons résultats.

Je combat le texte flou en passant à une police différente.

Évidemment, ce n'est pas une solution au problème, mais c'est ainsi que j'ai résolu le problème.


Je viens de comparer un TextBlock avec SnapToDevicePixels = "true" avec un sans et il n'y avait aucune différence avec la police Segoe UI à 12 jours. Puis-je vous demander quelles polices vous utilisez?
David Schmitt

Nous avons également amélioré la situation en changeant de police. La police que nous avons choisie était Avenir (je ne pense pas qu'elle soit installée par défaut, du moins pas sur Windows XP).
cplotts

0

Si vous préférez utiliser une classe de base C # pour personnaliser les fenêtres de votre application (ou si vous avez maintenant une raison de le faire), voici comment définir la mise en forme du texte pour utiliser le mode d'affichage attrayant:

public class SnappyWindow : Window
{
    public SnappyWindow()
    {
        SetValue(TextOptions.TextFormattingModeProperty, TextFormattingMode.Display);
    }
}
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.