Warum wird mein QML-CJK-Text mit beschädigten Glyphen gerendert?

Question

Meine Anwendung ermöglicht dem Benutzer, Sprachen im laufenden Betrieb zu wechseln. Ich sehe, dass etwa 10% der Zeit, die der Benutzer auf Chinesisch oder Japanisch wechselt, die Glyphen für den UI-Text falsch wiedergegeben werden.

Diese Anwendung läuft unter Linux auf einer iMX6-Plattform. Qt 5.5.0 wird verwendet. QML wird zum Rendern der Benutzeroberfläche verwendet. Der beschädigte Text wird mit einem QML-Text-Steuerelement gerendert.

Example of corrupt font rendering

Die Schrift in Frage verwendet wird, ist Quelle Hans Sans Regular. Ich habe versucht, das mit einem QML FontLoader zu laden und es auf der C++ - Seite in die Anwendungsschriftarten-Datenbank zu laden (beide Methoden zeigten das Problem). Ich habe versucht, die (zugegebenermaßen sehr stark verwandten) Noto-Schriften zu verwenden; gleiches Problem.

Ich habe noch nie Korruption von Text-Rendering gesehen, wenn Roboto für Nicht-CJK-Text verwendet und, wie erwähnt, dies funktioniert mehr als nicht für CJK/Source Hans Sans.

Die Korruption ist interessant, weil es so aussieht, als wäre es auf der gerenderten Bitmap-Ebene, nicht auf der Glyphen-Definitionsebene (beachten Sie, dass einige Glyphen die untere Hälfte korrekt haben, aber die obere Hälfte ist korrupt).

Korruption läuft manchmal weiter. Das führt mich zu der Annahme, dass der Cache-Speicher der Glyph-Bitmap weiter überschrieben wird (nur eine Theorie, da ich nicht sicher bin, wie Qt Font-Rendering ausführt). Ich dachte, es könnte die QML-Garbage-Collection sein, die etwas Seltsames macht, aber das Laden der Schriftart auf der C++ - Seite hat keinen Unterschied gemacht.

Ich werde versuchen, 'natives Rendering' für die QML Text-Steuerelemente verwenden.

Hat jemand das schon mal gesehen? Kann jemand bestätigen, dass FreeType für Font Management/Rendering unter Qt 5.5.0 verwendet wird? Gibt es Möglichkeiten, zu beeinflussen, wie der Font-Bitmap-Cache verwaltet wird?

Danke!

Update: Verwenden von 'renderType: Text.NativeRendering' löste das Problem nicht (obwohl die Korruption etwas anders manifestiert). Und angesichts der Einschränkungen dieses Modus endete am Ende mit schlecht wiedergegebenen Text (weiche, schlechte Skalierung usw. - as documented).

Update 2: Ich baute Qt mit (soweit ich weiß) alle Glyphen-Caches deaktiviert - shouldDrawCachedGlyphs() in meinem lokalen Build für die vier Instanzen dieser Anruf false zurück finde ich konnte - - aber immer noch Glyph Korruption.

Update 3: Versuchte Schalt zur Nutzung der Software (Nicht-OpenGL) Qt Quick 2-Renderer von QMLSCENE_DEVICE Einstellung = softwarecontext per docs; Glyphkorruption ist immer noch aufgetreten.

Answer 1

In diesem speziellen Fall gibt es einen Fehler im OpenGL-Treiber auf der Plattform, mit der ich arbeite. Es wirkt sich auf FBO-Rücklesevorgänge aus. Durch Setzen von QML_USE_GLYPHCACHE_WORKAROUND = 1 in der Umgebung wird Qt gezwungen, eine zusätzliche Kopie des Glyph-Caches im RAM zu behalten (da es beim Hinzufügen neuer Glyphen nicht von der Grafikhardware zurückgelesen werden kann).

Die Implikation davon ist, dass während das Rendering korrekt ist (da wir einen zweiten Cache verwenden, der nicht beschädigt ist) Leistung wird geringfügig verschlechtert, da eine zusätzliche Kopie auf der CPU und dem Glyphencache verwendet wird doppelt so viel Speicher. Die Renderqualität ist davon nicht betroffen.

Qt-Unterstützung war in der Lage, mich in die richtige Richtung zu weisen und die mit QML_USE_GLYPHCACHE_WORKAROUND verbundenen Implikationen zu qualifizieren.