Aus irgendeinem seltsamen Grund führt das Aufrufen von WinAPIs ExtTextOutW-Funktion zum Zeichnen von abgeschnittenem Text auf einer hochauflösenden Bitmap (2560x1440 / 3840x2160) zu einem Leistungsverlust von ~ x50, nachdem Windows 10 mit dem Creators-Aktualisierungsupdate aktualisiert wurde. Aus den Test- und Debug-Protokollen meines Benutzers wird ersichtlich, dass ein geringfügiger Unterschied in der Bitmap- oder möglicherweise der Schriftgröße den Leistungseinbruch auslösen kann.
Hier ist ein Debug-Log, der den Performance-Hit zeigt:
%Vor%Wie Sie aus dem Protokoll entnehmen können, dauert ein einzelner Aufruf von ExtTextgOutW ~ 9,5 ms, während derselbe Aufruf weniger als 1 ms dauerte, bevor das Ersteller-Update durchgeführt wurde.
Hier ist der eigentliche Code, den Sie mit der obigen Debug-Ausgabe vergleichen können:
%Vor%Dieser Code bewirkt einen sehr einfachen Schlagschatteneffekt, indem er den gleichen Text zweimal mit einem geringfügigen Unterschied in Y-Offset und Farbe rendert.
Hier ist die vollständige Diskussion mit meinen Forum-Benutzern, wo wir versuchen, das Problem auf einer Vielzahl von Hardware zu debuggen (zusätzliche Debug-Protokolle sind im Post enthalten): Ссылка
Wir haben mit DPI auf 100% getestet, um sicherzustellen, dass der Auslöser nicht mit den in der Creators Edition eingeführten DPI-Änderungen zusammenhängt.
Weiß jemand, was das auslöst? und gibt es einen Work-Around?
***** Update 1 *****
Zumindest beim ersten Test scheint "DrawTextExW" ebenfalls vom Leistungsverlust betroffen zu sein. Die verwendete Schriftart ist während des Tests Arial und die Leistungsprobleme scheinen mit der Schriftgröße zusammenzuhängen, da ein Benutzer berichtete, dass das Hinzufügen von Zeilen mit geringerer Größe auf dem Bildschirm (mehr Text wird mit einer niedrigeren Auflösung gerendert) die Leistung erheblich verbessert / p>
***** Update 2 *****
Ich habe ein kleines Tool geschrieben, um dieses Problem zu profilieren, das Sie in diesem GitHub-Repository finden können: Ссылка
Es scheint, dass das Problem von der Schriftgröße abhängt, zum Beispiel auf einem 2560x1440-Bildschirm, der eine Zeile mit "Arial" -Schrifttext mit einer Größe von "35" 21 ms rendert, während es bei einer Größe von "34" gerendert wurde 2ms.
Dies wird auf eine HDC einer Delphi TBitmap mit einem 32-Bit-Pixelformat gerendert, und das Deaktivieren von Clipping wirkt sich nur geringfügig auf die Leistung aus.
***** Update 3 *****
Sebastian Zs Antwort unten stellt das Leistungsniveau der Pre-Creators Edition wieder her und ich habe den Beispielcode auf GitHub aktualisiert, um seine Antwort zu reflektieren, aber seitdem konnte ich das Problem mit Windows 7 64bit und auf einem 1920x1080 Bildschirm reproduzieren, Es ist also nicht auf Windows 10-Ersteller oder hochauflösende Displays beschränkt, sondern der Trigger-Schwellenwert ist höher, wenn die Schriftqualität auf ANTIALIASED gesetzt ist. In meinem Test unter Windows 7, mit der Schriftart Arial, war der Triggerpunkt eine Schriftgröße von "109" (schnell) gegenüber einer Schriftgröße von "110" (x10 langsamer oder schlechter Leistung). Und dieser selbe Triggerschwellenwert existiert in Windows 10, nachdem Sebastian Zs Antwort verwendet wurde, um cleartype zu deaktivieren.
Delphi erstellt die Schrift mit lfQuality := DEFAULT_QUALITY; . Die Standardqualität war eine antialiasierte Qualität. Aber seit Windows 10 Creators dieses Update jetzt standardmäßig auf cleartype. Und das ist ziemlich langsam. Die Lösung besteht also darin, die Antialiasing-Qualität manuell zu erzwingen.
Wenn Sie eine aktuelle Delphi-Version verwenden, können Sie einfach die Font.Quality-Eigenschaft festlegen:
%Vor%In älteren Delphi-Versionen ist es etwas komplizierter:
%Vor%Dies ist eine echte Herausforderung in Windows 10 Creators Update, da ClearType-Text nicht immer geeignet ist und zu unerwarteten Ergebnissen führen kann.
Tags und Links windows delphi winapi high-resolution text-rendering