Problem z rozmazanymi czcionkami WPF - rozwiązania

Problem jest opisany i zademonstrowany pod następującymi linkami:

• Paul Stovell WPF: Renderowanie rozmytego tekstu
• forum www.gamedev.net
• Microsoft Connect: mechanizm renderowania tekstu WPF generuje źle rozmyty tekst na małych czcionkach

Objaśnienie: przejrzystość tekstu w WPF . Ten link zawiera porównanie czcionek.

Chciałbym zebrać wszystkie możliwe rozwiązania tego problemu. Microsoft Expression Blend używa WPF, ale czcionki wyglądają na czytelne.

• Ciemne tło jak w Microsoft Expression Blend
• Zwiększanie rozmiaru czcionki i zmiana czcionki (Calibri ...) [link]
• Osadź formularze systemu Windows [link]
• Użyj klasy TextRenderer GDI + i / lub Windows Forms, aby renderować tekst do mapy bitowej, a następnie renderuj tę mapę bitową jako kontrolkę WPF. [połączyć]

Czy jest więcej rozwiązań?

Zostanie to naprawione w VS2010 (i WPF4) beta 2

WYGLĄDA JAK TO W KOŃCU ROZWIĄZANE!

ComputerZen.com Scotta Hanselmana: WPF i rozmycie tekstu, teraz z pełną przejrzystością

Zaplecze techniczne

Istnieje szczegółowy artykuł na temat renderowania tekstu WPF z jednego z menedżerów programu tekstowego WPF w witrynie windowsclient.net: klarowność tekstu w WPF .

Problem sprowadza się do tego, że WPF wymaga liniowego skalowania renderowania czcionek w celu płynnych animacji. Z drugiej strony Pure ClearType wymaga sporej swobody dzięki czcionce, która przesuwa pionowe łodygi do następnego piksela.

Różnica jest oczywista, jeśli porównamy klasyczny wzór „kaskadowy”. WinForms w lewym dolnym rogu, WPF w prawym górnym rogu:

Chociaż nie jestem fanem idiosynkrazji związanych z renderowaniem czcionek WPF, mogę sobie wyobrazić wrzawę, gdyby animacje skakały tak, jak robią to w kaskadzie WinForm.

Zabawa z rejestrem

Szczególnie interesujące było dla mnie łącze do artykułu MSDN „ Ustawienia rejestru ClearType ”, w którym wyjaśniono możliwe korekty rejestru po stronie użytkownika:

• Poziom ClearType: ilość podpowiedzi subpikseli
• Poziom gamma
• Struktura pikseli: sposób ułożenia kolorowych pasków w pikselu wyświetlacza
• Poziom kontrastu tekstu: dostosowuje szerokość lasek glifów w celu zwiększenia ciężaru czcionki

Zabawa z tymi ustawieniami tak naprawdę nie poprawiła podstawowego problemu, ale może pomóc, zmniejszając efekt krwawienia kolorów dla wrażliwych użytkowników.

Inne podejście

Najlepszą radą zawartą w artykule Text Clarity było zwiększenie rozmiaru i zmiana czcionki. Calibri działa dla mnie lepiej niż standardowy interfejs Segoe. Ze względu na jej popularność jako czcionki internetowej wypróbowałem również Verdana, ale ma ona nieprzyjemny skok wagi między 14 a 15 punktami, co jest bardzo widoczne podczas animowania rozmiaru czcionki.

WPF 4.0

WPF 4 będzie miał ulepszoną obsługę wpływania na renderowanie czcionek. W blogu tekstowym WPF znajduje się artykuł wyjaśniający zmiany. Co najważniejsze, obecnie istnieją (co najmniej) trzy różne rodzaje renderowania tekstu:

_{<grumble> To powinno wystarczyć dla każdego projektanta. </grumble>}

NET 4 wreszcie ma rozwiązanie problemu słabej jakości renderowania tekstu WPF, ale jest dobrze ukryte. Ustaw następujące parametry dla każdego okna:

TextOptions.TextFormattingMode="Display"

Wartość domyślna to „Ideal”, co wcale nie jest tym, co sugeruje nazwa.

Istnieją dwie inne opcje w TextOptions, a mianowicie TextHintingMode i TextRenderingMode, ale obie mają rozsądne wartości domyślne.

Napotkałem problem pewnego dnia, kiedy użyłem obramowania, do którego zastosowano DropShadowEffect . W rezultacie cały tekst wewnątrz tej ramki był bardzo rozmyty. Nie ma znaczenia, czy tekst znajdował się wewnątrz innych paneli, czy bezpośrednio pod obramowaniem - każdy blok tekstu będący dzieckiem rodzica, który ma Efekt wydaje się, .

Rozwiązaniem tego konkretnego przypadku było nie umieszczanie rzeczy wewnątrz obramowania, które mają efekty, ale zamiast tego użyj siatki (lub czegokolwiek innego, co obsługuje umieszczanie treści jedna na drugiej) i umieść prostokąt w tej samej komórce co tekst (tj. jako rodzeństwo w drzewie wizualnym) i umieść na tym efekty.

Tak jak to:

<!-- 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>

To zostanie naprawione w VS2010 (i WPF4) beta 2:

SnapToDevicePixels dotyczy tylko kształtów WPF (linii itp.), A nie renderowania tekstu.

Nie jest znane obejście tego problemu. Według firmy Microsoft zachowanie jest zgodne z projektem.

Zobacz również ten wątek na forach Microsoft omawiający problemy - otrzymał kilka odpowiedzi od facetów z MS, które wyjaśniają ich stanowisko w tej sprawie.

Z punktu widzenia programisty jedynym znanym dotychczas „obejściem” jest użycie klasy TextRenderer GDI + i / lub Windows Forms do renderowania tekstu na bitmapie, a następnie renderowanie tej mapy bitowej jako kontrolki WPF. Pomijając oczywiste konsekwencje dla wydajności, nie zmniejsza to problemu dla istniejących aplikacji.

Utworzyłem teraz bilet Microsoft Connect dla tego problemu (ku mojemu zaskoczeniu, pomimo wszystkich negatywnych opinii, w wyznaczonym trackerze nie było rzeczywistego raportu o błędzie).

Ponieważ jest to jeden z oficjalnych kanałów przekazywania zapytań i zapytań do firmy Microsoft, radziłbym również przejść przez to, aby uzyskać szybszą odpowiedź. Przynajmniej, jeśli chcesz, aby problem został rozwiązany w taki czy inny sposób, głosowanie na ten bilet i / lub zatwierdzenie problemu pomoże zwrócić uwagę kierowników projektów firmy Microsoft i inżynierów na ten problem i prawdopodobnie podniesie jego postrzegany priorytet.

Nie uważam tego za błąd, ale domyślna konfiguracja jest rzeczywiście bardzo irytująca. Oto porównanie wszystkich kombinacji

TextOptions.TextRenderingMode
TextOptions.TextFormattingMode
RenderOptions.ClearTypeHint

SnapToDevicePixels nie powoduje żadnej różnicy w renderowaniu tekstu.

Wolę:

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

gdzie pionowe linie nigdy nie są rozmyte.

Użyta czcionka to Open Sans Light, która może być naprawdę piękna, jeśli jest dobrze używana, jak w najnowszym TeamViewerze.

Dla osób używających Mahapps.Metro problemem jest TransitioningContentControl https://github.com/MahApps/MahApps.Metro/issues/889

Właśnie wypróbowałem wersję beta VS2010, która jest wykonywana w WPF, i BADANIE cierpi z powodu problemu z rozmytą czcionką. Szczególnie w podpowiedziach.

Wydaje się to świadczyć o tym, że WPF4 w rzeczywistości nie rozwiąże problemu (jeśli już, to wygląda gorzej)

Wow, nie mogę uwierzyć, że w końcu moje czcionki WPF są czytelne. Nie mogę też uwierzyć, że nie ma okna dialogowego z opcjami, które ułatwiłoby te zmiany, podczas gdy domyślne wartości są okropne na moim ekranie.

Te ustawienia rejestru (w systemie dziesiętnym) działały dla mnie i są najbliższe mojej zwykłej czcionce zwykłej:

• ClearTypeLevel: 10 (głównie aliasing w skali szarości)
• GammaLevel: 1300 (wyższa gamma sprawiła, że ​​czcionka była zbyt cienka i widziałem kolory w aliasingu)

Mówią, że „SnapToDevicePixels = true” działa, ale nigdy nie widziałem żadnych dobrych wyników.

Z rozmytym tekstem walczę, przełączając się na inną czcionkę.

Oczywiście nie jest to rozwiązanie problemu, ale tak to obejrzałem.

Jeśli wolisz używać klasy bazowej C # do dostosowywania okien dla swojej aplikacji (lub teraz masz ku temu powód), oto jak ustawić formatowanie tekstu, aby używał atrakcyjnego trybu wyświetlania:

public class SnappyWindow : Window
{
    public SnappyWindow()
    {
        SetValue(TextOptions.TextFormattingModeProperty, TextFormattingMode.Display);
    }
}