Le problème est décrit et démontré sur les liens suivants:
Explication: Clarté du texte dans WPF . Ce lien contient une comparaison de polices.
Je voudrais rassembler toutes les solutions possibles à ce problème. Microsoft Expression Blend utilise WPF mais les polices semblent lisibles.
Y a-t-il d'autres solutions?
Ceci va être corrigé dans VS2010 (et WPF4) beta 2
IL RESSEMBLE COMME IL A ÉTÉ FINALEMENT RÉSOLU!
ComputerZen.com de Scott Hanselman: WPF et Blurriness de texte, maintenant avec une clarté complète
Il existe un article détaillé sur le rendu du texte WPF par l’un des responsables du 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 moteur de rendu des polices à mise à l’échelle linéaire pour des animations fluides. De son côté, Pure ClearType prend un peu de liberté avec la police pour pousser les tiges verticales dans le pixel suivant.
La différence est évidente si on compare le modèle classique de "cascade". WinForms en bas à gauche, WPF en haut à droite:
Bien que je ne sois pas non plus fan des idiosyncrasies de rendu des polices de WPF, je peux imaginer la clameur si les animations sautaient comme dans la cascade Winforms.
Le lien vers l'article MSDN " ClearType Registry Settings " m'a particulièrement intéressé, ce qui explique les ajustements possibles du côté du registre dans le registre:
L'utilisation de ces paramètres n'améliore pas vraiment le problème sous-jacent, mais peut aider à réduire l'effet de perte de couleur pour les utilisateurs sensibles.
Le meilleur conseil que l'article Text Clarity a donné a été d'augmenter la taille de la police et de la modifier. Calibri fonctionne mieux pour moi que l'interface utilisateur standard de Segoe. En raison de sa popularité en tant que police Web, j’ai aussi essayé Verdana, mais son poids varie entre 14 et 15 points, ce qui est très visible lors de l’animation de la taille de la police.
WPF 4 aura un support amélioré pour influencer le rendu des polices. Il y a n article sur le blog textuel WPF expliquant les modifications. Plus particulièrement, il existe au moins trois types différents de rendu de texte:
<grumble> Cela devrait être suffisant pour chaque designer. </ grumble>
NET 4 a enfin une solution à la mauvaise qualité de rendu du texte de WPF, mais elle est bien cachée. 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 son nom implique.
Il existe deux autres options dans TextOptions, à savoir TextHintingMode et TextRenderingMode, mais elles ont toutes les deux des valeurs par défaut raisonnables.
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 que le texte se trouve à l'intérieur d'autres panneaux ou directement sous la bordure - tout bloc de texte enfant du parent auquel un Effet appliqué semble être affecté.
La solution à ce cas particulier était de ne pas placer d'éléments insérés dans la bordure qui ont des effets, mais plutôt d'utiliser une grille (ou tout autre élément permettant de placer le contenu l'un sur l'autre) et de placer un rectangle dans la même cellule que le texte (c'est-à-dire comme un frère dans l'arbre visuel) et mettre les effets sur cela.
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>
Du point de vue du développeur, la seule "solution de contournement" connue à ce jour consiste à utiliser la classe TextRenderer GDI + et/ou Windows Forms pour restituer le texte en bitmap, puis à restituer ce bitmap sous forme de contrôle WPF. Mis à part 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 aucun rapport de bogue dans le suivi spécifié).
Étant donné qu’il s’agit de l’un des canaux officiels de communication des demandes et des questions à Microsoft, je vous conseillerais également de le parcourir pour obtenir une réponse plus rapide. Au moins, si vous souhaitez que le problème soit traité d'une manière ou d'une autre, voter pour ce ticket et/ou valider le problème aidera à attirer l'attention des chefs de projet et des ingénieurs de Microsoft sur ce problème, et éventuellement à en augmenter la priorité.
SnapToDevicePixels s'applique uniquement aux formes WPF (lignes, etc.) et non au rendu de texte.
Solution de contournement connue à ce problème. Selon Microsoft, le comportement est "par conception".
Voir également le fil this sur les forums Microsoft qui traite des problèmes - il a reçu quelques réponses de types MS qui clarifient leur position sur la question.
Je viens d'essayer la version bêta de VS2010, qui est entièrement réalisée dans WPF, et qui souffre BADLY du problème des polices floues. Particulièrement sur les info-bulles.
Cela semble indiquer que WPF4 ne résoudra pas le problème (si quelque chose semble pire)
Je ne le vois pas comme un bug, mais la configuration par défaut est en effet très gênante. 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.
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, ce qui peut s'avérer très utile 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
Wow, je ne peux pas croire que mes polices WPF soient enfin lisibles. Et je ne peux pas non plus croire qu’il n’existe aucune boîte de dialogue d’option pour faciliter ces modifications alors que les valeurs par défaut sont horribles sur mon écran.
Ces paramètres du registre (en décimal) ont fonctionné pour moi et se rapprochent le plus de ma police cleartype habituelle:
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.
De toute évidence, ce n’est pas une solution au problème, mais c’est ainsi que j’ai résolu ce problème.
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 vous pouvez 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);
}
}