मेरा क्यूएमएल सीजेके पाठ दूषित ग्लिफ के साथ क्यों प्रस्तुत किया जा रहा है?

Question

मेरा आवेदन उपयोगकर्ता मक्खी पर भाषाओं स्विच करने के लिए अनुमति देता है। मैं देख रहा हूं कि उपयोगकर्ता चीनी या जापानी में स्विच करने के लगभग 10%, यूआई पाठ के लिए ग्लिफ अनुचित रूप से प्रस्तुत किए जा रहे हैं।

इस एप्लिकेशन को किसी iMX6 मंच पर लिनक्स के तहत चल रहा है। क्यूटी 5.5.0 का उपयोग किया जा रहा है। क्यूएमएल यूआई प्रस्तुत करने के लिए प्रयोग किया जाता है। एक क्यूएमएल पाठ नियंत्रण का उपयोग कर भ्रष्ट पाठ प्रस्तुत किया जा रहा है।

Example of corrupt font rendering

प्रश्न में इस्तेमाल किया जा रहा फ़ॉन्ट स्रोत हंस संस नियमित है। मैंने इसे QML FontLoader का उपयोग करके लोड करने का प्रयास किया है और इसे C++ पक्ष पर एप्लिकेशन फ़ॉन्ट डेटाबेस में लोड करके (दोनों विधियों ने समस्या का प्रदर्शन किया है)। मैंने (स्वीकार्य रूप से बहुत दृढ़ता से संबंधित) नोटो फोंट का उपयोग करने की कोशिश की है; एक ही समस्या है।

जब गैर CJK पाठ के लिए रोबोटो का उपयोग करने और, के रूप में उल्लेख किया है मैं पाठ प्रतिपादन के भ्रष्टाचार कभी नहीं देखा है, इस CJK/स्रोत हंस संस के लिए नहीं की तुलना में अक्सर काम करता है।

भ्रष्टाचार दिलचस्प है क्योंकि ऐसा लगता है कि यह प्रस्तुत बिटमैप स्तर पर है, न कि ग्लिफ परिभाषा स्तर (ध्यान दें कि कुछ ग्लिफ के पास आधा सही है, लेकिन शीर्ष आधा भ्रष्ट है)।

भ्रष्टाचार कभी कभी प्रगति करता है। यह मैं सुराग ग्लिफ़ बिटमैप कैश स्मृति आगे ओवरराइट किया जा रहा है (सिर्फ एक सिद्धांत के रूप में मुझे यकीन है कि कैसे क्यूटी फ़ॉन्ट रेंडरिंग करता है नहीं कर रहा हूँ) में सोचने के लिए। मैंने सोचा कि यह क्यूएमएल कचरा संग्रह कुछ अजीब कर सकता है, लेकिन सी ++ पक्ष पर फ़ॉन्ट लोड करने से कोई फर्क नहीं पड़ता।

मैं क्यूएमएल पाठ नियंत्रण के लिए 'मूल प्रतिपादन' का उपयोग करने की कोशिश करने जा रहा हूं।

क्या किसी ने इसे पहले देखा है? क्या कोई भी क्यूटी 5.5.0 के तहत फ़ॉन्ट प्रबंधन/प्रतिपादन के लिए फ्रीटाइप का उपयोग कर सकता है? क्या इस बात को प्रभावित करने के तरीके हैं कि फ़ॉन्ट बिटमैप कैश कैसे प्रबंधित किया जाता है?

धन्यवाद!

अद्यतन: 'रेंडर टाइप: टेक्स्ट.NativeRendering' का उपयोग करके समस्या को खत्म नहीं किया (हालांकि भ्रष्टाचार थोड़ा अलग दिखाई देता है)। और, उस विधा की सीमाओं, बस आम तौर पर खराब गाया पाठ (मुलायम, गरीब स्केलिंग, आदि - as documented) के साथ समाप्त हो गया दिया।

अद्यतन 2: - shouldDrawCachedGlyphs() है कि कॉल मैं ढूँढने में सक्षम था के चार मामलों के लिए अपने स्थानीय निर्माण में झूठी देता है मैं के साथ (मैं जानता हूँ कि जहाँ तक) ग्लिफ़ के सभी कैश विकलांग क्यूटी बनाया - - लेकिन अभी भी ग्लिफ भ्रष्टाचार का सामना करना पड़ा।

अद्यतन 3: QMLSCENE_DEVICE = softwarecontext per docs की स्थापना करके सॉफ्टवेयर (गैर ओपन) क्यूटी त्वरित 2 रेंडरर का उपयोग करने के लिए स्विचन की कोशिश की; ग्लिफ भ्रष्टाचार अभी भी हुआ।

Answer 1

इस विशेष मामले में, जिस प्लेटफॉर्म पर मैं काम कर रहा हूं उस पर ओपनजीएल ड्राइवर में एक बग है। यह एफबीओ रीडबैक को प्रभावित करता है। पर्यावरण में QML_USE_GLYPHCACHE_WORKAROUND = 1 सेट करना क्यूटी में रैली में ग्लिफ कैश की एक अतिरिक्त प्रतिलिपि रखने के लिए क्यूटी (क्योंकि इसे नए ग्लिफ जोड़े जाने पर ग्राफिक्स हार्डवेयर से वापस नहीं पढ़ा जा सकता है)।

इसका निहितार्थ यह है कि प्रतिपादन सही होगा (चूंकि हम एक दूसरे कैश का उपयोग कर रहे हैं जो भ्रष्ट नहीं है) प्रदर्शन सीपीयू पर अतिरिक्त प्रतिलिपि होने के बाद थोड़ा कम हो जाएगा और ग्लिफ कैश का उपयोग होगा दो गुना ज्यादा स्मृति। रेंडरिंग गुणवत्ता अप्रभावित है।

क्यूटी समर्थन मुझे सही दिशा में इंगित करने और QML_USE_GLYPHCACHE_WORKAROUND से जुड़े प्रभावों को अर्हता प्राप्त करने में सक्षम था।