Pixi.js: प्रस्ताव: टेक्स्ट रेंडरिंग में सुधार

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

पिक्सी एसडीएफ सही उदाहरण है।

कृपया, PIXI से फेजर बनाने की कोशिश न करें

मैं कुछ और संदर्भ देना चाहूंगा। मैंने @SukantPal से वैकल्पिक टेक्स्ट/बिटमैप टेक्स्ट दृष्टिकोणों पर शोध करने के लिए कहा है

मुझे लगता है कि यहां कई दृष्टिकोण हैं। कुछ तीसरे भाग प्लगइन्स के रूप में उपयुक्त हो सकते हैं, कुछ रेपो में हो सकते हैं लेकिन बंडल नहीं किए जा सकते हैं, और कुछ मौजूदा एपीआई को प्रतिस्थापित/संवर्धित कर सकते हैं। आइए जानें कि सबसे उपयोगी टेक्स्ट रेंडरिंग दृष्टिकोण क्या है जो प्रदर्शन के लिए अनुकूलित करता है लेकिन बिटमैपटेक्स्ट में कम ट्रेड-ऑफ के साथ।

मानदंड के कुछ टुकड़े हैं जिनका उपयोग मैं न्यायाधीश को एक अच्छे टेक्स्ट डिस्प्ले ऑब्जेक्ट का उपयोग करूंगा:

• अच्छा रनटाइम प्रदर्शन - पाठ प्रस्तुत करना और पाठ बदलना कम लागत वाला है
• कम मेमोरी - रैम का उपयोग कम है
• छोटी निर्भरता - निर्भरता पदचिह्न फ़ाइल का आकार छोटा है
• ग्रेट फिडेलिटी - विभिन्न संकल्पों के साथ अच्छी तरह से काम करता है
• लचीली स्टाइलिंग - स्ट्रोक, ड्रॉप शैडो, ग्रेडिएंट के लिए समर्थन
• बड़ी ग्लिफ़ भाषाओं का समर्थन करता है - जैसे, चीनी, जापानी, कोरियाई
• पिछड़ा संगत - Context2D के साथ काम करता है

| | परफ | मेमोरी | निर्भरता | निष्ठा | स्टाइलिंग | सीजेके | Context2d |
|--|--|--|--|--|--|--|--|
|पाठ| | | | | | | | |
|बिटमैपपाठ| | | | | | | |

ठीक।
fragment interpolation और सभी गैर-देशी कार्यान्वयन का वर्णन करता है:

1. अतिरिक्त शेडर और अतिरिक्त डेटा की आवश्यकता है - इससे बैचिंग को रोका जा सकेगा।
2. परिवर्तन के समय ज्यामिति के पुनर्निर्माण की आवश्यकता होती है (पृष्ठ 3)।
3. भाषा में मौजूद सभी ग्लिफ़ के लिए एक ग्लिफ़-टेबल की आवश्यकता होती है, जिसके लिए पूरी तरह से मेमोरी में लोड विशिष्ट टीटीएफ की आवश्यकता होती है, क्योंकि ओटी स्ट्रीमिंग का समर्थन नहीं कर सकता है, और फिर इसे पार्स कर सकता है। एसडब्ल्यूएफ की तरह दिखता है।
   क्योंकि हम सिस्टम फ़ॉन्ट को आकार के रूप में लोड नहीं कर सकते - हम इसका उपयोग नहीं कर सकते।
4. भाषा विशिष्ट नियम ब्राउज़र टीम से lib टीम में जा रहे हैं, जो नियमों को प्रस्तुत करते हैं: एलटीआर/आरटीएल, हिंदी/अरबी ग्लिफ कॉन्सटेनेशन नियम इत्यादि ... 10% ब्राउज़र को lib में ले जाने के समान। एकता अभी भी इसे लागू नहीं कर रही थी।
5. सहायक शैलियों के लिए अतिरिक्त तर्कों के साथ भारी शेडर। इससे रेंडर कॉस्ट बढ़ जाती है, क्योंकि हमें इसे रियल टाइम में रेंडर करना चाहिए।
   और निश्चित रूप से हमें इसे बनावट के रूप में कैश करना चाहिए।

@eXponenta

• टेक्स्ट को बैच किया जा सकता है - हालांकि ग्राफिक्स जैसे अन्य सामान के साथ नहीं।

• वर्तमान टेक्स्ट कार्यान्वयन प्रत्येक ग्लिफ़ को कई बार कैश करता है (यदि एक अक्षर का उपयोग कई PIXI.Texts में कई बार किया जाता है)। प्रति ग्लिफ़ में एक ज्यामिति होना बेहतर है। इसके अलावा, आपको विभिन्न फ़ॉन्ट आकारों में कैश करने की आवश्यकता नहीं है।

• ज्यामिति को प्रति कहने के लिए फिर से बनाने की आवश्यकता नहीं है - यदि पाठ में अक्षर बदलते हैं, तो आपको ग्लिफ़ ज्यामिति तालिका से फिर से लाने की आवश्यकता है। यदि परिवर्तन बदलता है, तो आपको केवल एक वर्दी बदलने की आवश्यकता है।

• हम फॉन्ट पार्सिंग के लिए लाइब्रेरी का उपयोग कर सकते हैं। ज्यामिति में रूपांतरण तुच्छ है।

• मुझे नहीं पता कि ग्लिफ़ संयोजन नियम क्या हैं। क्या आप समझाएँगे?

• बाएँ-से-दाएँ बनाम दाएँ-से-बाएँ - यदि आप अक्षरों को उलटना चाहते हैं, तो आप कर सकते हैं। यदि आप मिरर इमेज चाहते हैं, तो आंतरिक रूप से scale.x=-1 सेट करें।

• टेक्स्ट स्टाइलिंग शेडर में अधिक तर्क नहीं जोड़ेगी। यह ज्यामिति को बदल देगा। अब, ग्लिफ़ को ज्यामिति के रूप में संग्रहीत करने से बनावट में कैशिंग करने की तुलना में _less_ मेमोरी लगती है।

• एपीआई से प्राप्त फ़ॉन्ट फ़ाइलें उपयोगकर्ता की मशीन पर कैश की जानी चाहिए।

आप बहुत भोले हैं:

1. यह बाहरी बैचर होना चाहिए, क्योंकि ग्लिफ़ को अतिरिक्त विशेषता की आवश्यकता होती है, जैसे कि बेज़ियर एंकर, छाया मान, ग्रेडिएंट एंकर ..., या सभी को वर्दी के रूप में पारित किया जाना चाहिए - अलविदा, बैचिंग।
2. दाएं से बाएं और बाएं से दाएं, और उनका मिश्रण बहुत जटिल समस्या है।
   पीडीएफ रेंडरिंग लिब में खुले मुद्दे:
   https://github.com/asciidoctor/asciidoctor-pdf/issues/175
3. हिंदी समस्या (और इसी तरह की भाषा)
   https://docs.microsoft.com/en-us/typography/opentype/spec/gsub

हम बाहरी निर्भरता का उपयोग नहीं कर सकते, क्योंकि isMobile या resource-loader जैसी ही समस्या होगी।
कोर साफ होना चाहिए। न्यूनतम बाहरी निर्भरता।

@eXponenta

• मिश्रित लेआउट (ltr और rtl संयुक्त) उच्च प्रदर्शन की तुलना में प्राथमिकता से कम है। आप हमेशा वर्तमान एल्गोरिदम पर वापस आ सकते हैं। देवनागरी के लिए समान। ग्रेडिएंट स्टॉप जैसी विशेष सुविधाओं को भी कमबैक की आवश्यकता होगी।

• यहां बैचिंग काम कर सकती है क्योंकि बिना किसी टेक्सचर के यह आसान हो जाएगा। CanvasGraphicsRenderer जैसा प्लगइन बना सकते हैं।

ठीक। आप जीत गए। इसे करें। लेकिन कोर के बाहर, फिर हम इसे देखेंगे और तय करेंगे कि हमें क्या करना चाहिए।
लेकिन भारी निर्भरता के बिना।

@eXponenta कृपया इतना शत्रुतापूर्ण होना बंद करें। हम दृष्टिकोण तलाश रहे हैं अभी कुछ भी ठोस नहीं है। कृपया रचनात्मक रहें और अपमान का प्रयोग न करें।

@eXponenta क्या आप सुनिश्चित हैं कि हम अभी दाएं-से-बाएं पाठ का समर्थन करते हैं?

एक और तरीका जो हम सोच रहे हैं, वह यह है कि प्रत्येक ग्लिफ़ को कैनवास 2D (अभी के समान) का उपयोग करके अलग से प्रस्तुत किया जाए और उन्हें एटलस में कैश किया जाए। एटलस को सभी PIXI.Text उदाहरणों के लिए विश्व स्तर पर पुन: उपयोग किया जा सकता है। प्रत्येक ग्लिफ़ + फ़ॉन्ट-आकार + फ़ॉन्ट-शैली संयोजन अलग से कैश किया जाएगा।

आप इसे मूल रूप में स्वीकार करने के बारे में क्या सोचते हैं?

अरे झाँक, मेज पर इन नए दृष्टिकोणों को सुनना वाकई रोमांचक है। @eXponenta , करते हुए, कृपया इसे रचनात्मक रखें। नए प्रस्तावित दृष्टिकोण में आपके पास स्पष्ट रूप से कुछ अच्छी अंतर्दृष्टि है, लेकिन यह देखने का लक्ष्य है कि क्या हम उठाए गए मुद्दों को कम कर सकते हैं और इसे अनुकूल रख सकते हैं :)

पाठ पर, मेरे 2 सेंट (पेंस?)

व्यक्तिगत रूप से मुझे लगता है कि बिटमैप टेक्स्ट की गति और प्रदर्शन हासिल करना सबसे मूल्यवान तरीका है, लेकिन वास्तव में पहले से बिटमैप फ़ॉन्ट बनाने की आवश्यकता के बिना। गतिशील बिटमैप बनावट निर्माण यदि आप करेंगे!

गतिशील बिटमैप फोंट

पेशेवरों

• बिटमैप फोंट बनाने के लिए उपकरण कुछ ही हैं और बीच में बहुत दूर हैं! उस बाधा को दूर करना अच्छा लगेगा।
• हम टेक्स्ट आकार बनावट के विभिन्न आकार बना सकते हैं।
• Canvas . में काम करता है
• प्रत्येक ग्लिफ़ के रूप में प्रदर्शन को बैच किया जा सकता है
• बहुत सारे शांत प्रभाव!
• एपीआई को केवल मामूली समायोजन की आवश्यकता होगी:

const textStyle = new TextStyle({
    font:'comic sans',
    fill:'bright green'
});


const bitmapFont = new BitmapFont(textStyle);

दोष

• बिटमैप वर्तमान बिटमैप फोंट के अन्य सभी विपक्ष: पी
• बनावट एटलस को गतिशील रूप से अद्यतन करने से धीमा हो जाएगा?
  
  
  
  • हालांकि यह थोड़ी देर बाद स्थिर हो जाएगा, और शायद सत्रों के बीच कैश किया जा सकता है?
  
  
  • वर्तमान पाठ को हर बार फ्रेम बदलने पर एक बनावट अपलोड करनी होती है, यह दृष्टिकोण इसे कम करेगा?
  
  

विचारों

• स्थानीय स्टोरेज में कैश बनावट उत्पन्न कर सकता है? बाद की यात्राओं के लिए?
• केवल उपयोग किए गए वर्ण जोड़ें, ताकि बनावट उतनी ही बड़ी हो जितनी उसे होनी चाहिए। हमारे जाते ही अपडेट करें
• अतिरिक्त शांत प्रभावों (रूपरेखा, छाया आदि) के लिए इस बनावट में फिल्टर में सेंकना
• हम प्रत्येक ग्लिफ़ को स्प्राइट न बनाकर बिटमैप फ़ॉन्ट की मेमोरी को कम कर सकते हैं?

एसडीएफ
क्या एसडीएफ उपरोक्त दृष्टिकोण का विस्तार हो सकता है? उस बनावट को गतिशील रूप से उत्पन्न करना कितना जटिल होगा? क्या यह सुपर जानकी होगा? क्या हम कोड आधार को बड़ी मात्रा में बढ़ाने की बात कर रहे हैं?

अधिकांश लोगों को पता नहीं है कि वह क्या है इसलिए इसे आदर्श रूप से छिपाया जाना चाहिए। यदि हमें बाहरी रूप से एसडीएफ फ़ील्ड उत्पन्न करने की आवश्यकता है या उत्पन्न करने के लिए आवश्यक कोड बहुत बड़ा या जटिल है तो यह निश्चित रूप से प्लगइन के रूप में घर पर बेहतर होगा:

const textStyle = new TextStyle({
    font:'comic sans',
    fill:'bright green',
    sdf:true, <----- how sweet would this be, maybe rename to more user friendly like 'cleanEdges'
});

const sdfFont = new BitmapFont(textStyle);

सटीक बेजियर वक्र प्रतिपादन

यह निश्चित रूप से एक दिलचस्प तरीका है! मैंने अतीत में इस पर गौर किया था और फैसला किया था कि शेडर स्विच को रेंडरिंग लूप में पेश किया गया था और अतिरिक्त टेसेलेशन की आवश्यकता होगी जो एक बड़ा ओवरहेड होगा। @ सुकांतपाल , आप अभी इस विचार के करीब हैं, इसलिए मैं अपनी चिंताओं पर अपना विचार रखना चाहता हूं!

ऐसा कहने के बाद, शायद यह एक प्रोटोटाइप बनाने के लायक हो सकता है जिसे हम परीक्षण कर सकते हैं और अपनी सोच को मान्य करने के लिए थोड़ा सा धक्का दे सकते हैं?

पाठ के लिए रोमांचक समय :D

क्या एसडीएफ उपरोक्त दृष्टिकोण का विस्तार हो सकता है? उस बनावट को गतिशील रूप से उत्पन्न करना कितना जटिल होगा? क्या यह सुपर जानकी होगा? क्या हम कोड आधार को बड़ी मात्रा में बढ़ाने की बात कर रहे हैं?

एसडीएफ उत्पादन महंगा है, और एक पैकिंग समय होता है (जब हम एटलस में अलग-अलग फोंट पैक करते हैं), लेकिन इसे क्लाइंट (अन्य सभी प्रकार के रूप में) पर कैश किया जा सकता है।
इसका एक कैनवास (हेहे) कार्यान्वयन है:
https://github.com/mapbox/tiny-sdf
लेकिन एसडीएफ संकलन पूरी तरह से सही नहीं है (फ़ॉन्ट आकार बढ़ाने/घटाने पर ग्लिफ़ बदल जाता है)
उपयोगी लगता है, लेकिन MSDF के लिए हमें इसे 3 बार (प्रति चैनल) निष्पादित करना चाहिए।

ओह वाह, यह एक छोटा सा कोड है! एक शेडर भी करने के लिए परिपक्व लग रहा है!

@GoodBoyDigital छोटा- sdf पैकेज एकल चैनल दूरी फ़ील्ड उत्पन्न करता है। जब आप टेक्स्ट को छोटे फ़ॉन्ट आकारों में कैश करते हैं तो यह नुकीले कोनों का उत्पादन नहीं करता है। इसे उसी फ़ॉन्ट आकार में कैशिंग करके कम किया जा सकता है जिसे प्रस्तुत किया जा रहा है।

एकल चैनल SDF पीढ़ी बहुत खराब नहीं होनी चाहिए। मल्टी चैनल एसडीएफ बेहतर है सिवाय इसके कि यह बहुत जटिल है। मैं समझ नहीं पा रहा था कि कैसे चुमस्कली कोनों को कूटबद्ध कर रहा था।

अब, हम जो कुछ भी विचार कर रहे हैं वह आरटीएल और @eXponenta ने सही ढंग से बताया)। लेकिन मुझे नहीं लगता कि हम अभी आधिकारिक तौर पर इसका समर्थन कर रहे हैं।

सटीक दृष्टिकोण के दो लाभ हैं - छोटे कैश आकार (आप सभी पिक्सल नहीं कैशिंग कर रहे हैं), सेटिंग "एंटीअलाइजिंग" बंद होने पर भी एंटीअलाइजिंग (पाठ हमेशा एंटीअलाइज्ड होने की उम्मीद है मुझे लगता है। वर्तमान कार्यान्वयन कैनवास का उपयोग करके करता है 2डी)।

डेमो के लिए, क्या आपने मेरे द्विघात बेज़ियर वक्र डेमो को देखा? https://codepen.io/sukantpal/pen/GRJawBg?editors=0010

——
एक और बात जो मैंने और @bigtimebuddy ने सबसे सरल समाधान के रूप में चर्चा की, वह थी कैनवास 2D का उपयोग करना और ग्लिफ़ को एक बनावट में कैश करना। ग्लिफ़ को क्वाड के रूप में प्रस्तुत किया जा सकता है। कैश एटलस को ग्रंथों के बीच पुन: उपयोग किया जा सकता है। बेशक, इसका मतलब है कि बड़े टेक्स्ट को एक ही आकार में कैश किया जा रहा है और इसलिए बड़ी मेमोरी का उपयोग जब बहुत सारे टेक्स्ट को प्रस्तुत किया जा रहा है, लेकिन इसका केवल एक हिस्सा (जैसे पीडीएफ में वर्तमान पृष्ठ) दिखाई दे रहा है।

अच्छा,

हां, आरटीएल या एलटीआर के बारे में कोई चिंता नहीं है जो हमेशा वर्तमान पद्धति के माध्यम से उपलब्ध होगी और एक समस्या है जिसे सभी कस्टम टेक्स्ट रेंडरिंग तकनीकों को बाद की तारीख में हल करने की आवश्यकता होगी।
ये फैसले। आदर्श रूप से स्मृति खपत और रनटाइम प्रदर्शन पर ध्यान केंद्रित किया जाना चाहिए।

बेज़ियर डेमो अच्छा है, लेकिन मुझे नहीं लगता कि अगर हम एक पूर्ण वाक्य प्रस्तुत करते हैं, तो यह उन वास्तविक जटिलताओं को समझने के लिए पर्याप्त है जो छिपी हो सकती हैं।

मैंने ऊपर डायनामिक बिटमैपफोंट के बारे में जो सामान लिखा है, वह ठीक वैसा ही है जैसा आपने ग्लिफ़ कैशिंग के बारे में बताया था। मुझे लगता है कि यह निश्चित रूप से नीचे जाने का एक उपयोगी मार्ग है!

सारांश:

बेजियर वक्र समाधान: यह अच्छा मार्ग हो सकता है, लेकिन मुझे लगता है कि यह वास्तविक उत्पादन उपयोग के मामलों में कैसे फिट बैठता है, यह जानने के लिए और आर एंड डी की आवश्यकता है।

सामान्य फोंट से गतिशील बिटमैपफोंट: हमें निश्चित रूप से इसका पता लगाना चाहिए क्योंकि हम जानते हैं कि यह एपीआई को सरल रखते हुए अच्छा प्रदर्शन देगा। मेरा पसंदीदा: डी

सिंगल चैनल एसडीएफ इसकी सराहना करता है कि यह उतना अच्छा मल्टीचैनल एसडीएफ नहीं होगा, लेकिन डेमो मुझे बहुत अच्छा लगा! यदि टेक्स्ट अच्छी तरह से स्केल कर सकता है और हमारे पास प्रति फ़ॉन्ट एक बनावट हो सकती है, तो मुझे लगता है कि यह मार्ग भी जांच के लायक हो सकता है!

@GoodBoyDigital मुझे लगता है कि डेमो में बहुत अच्छा टेक्स्ट है। लेकिन यदि आप विवरण देखने की कोशिश करते हैं तो अंतर दिखाई देता है:

शीर्ष पर पाठ तेज नहीं है - किनारों में झिलमिलाहट है। प्रत्येक फ़ॉन्ट+(फ़ॉन्ट-आकार में ~12-15px अंतर) संयोजनों को अलग से कैश करने की आवश्यकता हो सकती है।

मैं एसडीएफ के लिए जाने के साथ पूरी तरह से ठीक हूं यदि वे विगल्स महत्वहीन हैं या यदि हम कई फ़ॉन्ट आकारों में कैशिंग के साथ जा सकते हैं।

सबसे आसान उपाय भी मेरे लिए ठीक है tbh!

सभी को प्रणाम।

मैं पिक्सी की सभी चीजों पर एक सुपर आम आदमी हूं, लेकिन जीडीवेलप का उपयोगकर्ता हूं जो पिक्सी को अपने बैकएंड के रूप में उपयोग करता है, और मैं कुछ समय के लिए पिक्सीजेएस के जीडीवेलप के कार्यान्वयन और टेक्स्ट प्रतिपादन के लिए खुदाई कर रहा हूं। यह वास्तव में उस गेम के लिए प्रभावशाली है जिस पर मैं काम कर रहा हूं जिसमें बहुत सारे टेक्स्ट हैं। (मेरे द्वारा GDevelop में पोस्ट की गई समस्या में आप मेरे शोध/उदाहरण देख सकते हैं: https://github.com/4ian/GDevelop/issues/1449 )

मुझे मिले विकल्पों में से एक टेक्स्ट के साथ स्केलिंग मुद्दों को पूरी तरह से अनदेखा करने और टेक्स्ट स्केल को हमेशा 100% पर छोड़कर उन्हें पूरी तरह से समाप्त करने पर केंद्रित था, लेकिन इसके बजाय टेक्स्ट फ़ॉन्ट आकार को स्केल करना? यह फ़ॉन्ट अज्ञेयवादी है, और सभी आकारों में काम करता प्रतीत होता है।

यहां एक कोड उदाहरण दिया गया है जहां यह पिक्सी का उपयोग करके किया जा रहा है: https://codepen.io/Tazy/pen/wJVExB
मैंने इसे इस सूत्र में पाया: https://www.html5gamedevs.com/topic/29576-scalable-text-for-pixijs/

मुझे वास्तव में इस मुद्दे पर एक इनाम है क्योंकि मैं उम्मीद कर रहा था कि कोई व्यक्ति जीडीवेलप के लिए पिक्सी टेक्स्ट एक्सटेंशन को संशोधित कर सकता है, लेकिन (आम आदमी होने के नाते) मुझे नहीं पता था कि यह पिक्सी के साथ एक बहुत बड़ा मुद्दा था।

कोई विचार नहीं है कि इस पद्धति के साथ संभावित समस्याएं हैं, लेकिन ऐसा लगता है कि यह एसडीएफ/एमएसडीएफ/आदि के सभी प्रदर्शन मुद्दों से बचने के लिए प्रतीत होता है।

@ सिल्वर-स्ट्रीक यदि आपका मतलब टेक्स्ट डिस्प्ले-ऑब्जेक्ट पर लागू पैमाने से फ़ॉन्ट-आकार बढ़ाना है, तो यह प्रदर्शन के मामले में बेहतर कैसे होगा? SDF सामग्री प्रदर्शन में मदद करती है क्योंकि आप बड़े फ़ॉन्ट-आकारों में पुन: प्रस्तुत नहीं करते हैं।

@ सिल्वर-स्ट्रीक बेशक, आपका प्रस्ताव _गुणवत्ता_ में सुधार करेगा लेकिन मुझे नहीं लगता कि यह प्रदर्शन में सुधार कैसे करेगा।

@ सिल्वर-स्ट्रीक बेशक, आपका प्रस्ताव _गुणवत्ता_ में सुधार करेगा लेकिन मुझे नहीं लगता कि यह प्रदर्शन में सुधार कैसे करेगा।

जब तक मैं गलतफहमी नहीं कर रहा हूं, फ़ॉन्ट आकार को बदलने से पूरे ऑब्जेक्ट को स्केल करने या किसी अन्य रेंडरर में लोड करने से कम संसाधनों का उपयोग नहीं होगा? फिर, मैं सुपर आम आदमी हूं जब यह आता है कि पिक्सी की स्केलिंग वास्तव में कैसे काम करती है, यह सिर्फ मेरे लिए समझ में आता है कि मूल संकल्प पर फ़ॉन्ट छोड़ना लेकिन टेक्स्ट आकार बदलना इसे स्केल करने से तेज़ होगा। अगर यह गलत है, तो ध्यान भंग करने के लिए खेद है।

@ सिल्वर-स्ट्रीक स्केलिंग को एक परिवर्तन के रूप में लागू किया गया है। आपके पास एक परिवर्तन मैट्रिक्स है - और उस मैट्रिक्स में पैमाने को बदलना एक छोटा ऑपरेशन है।

अभी तक, टेक्स्ट को कैनवास 2डी एपीआई का उपयोग करके कैनवास में प्रस्तुत किया जाता है। फिर इसे स्क्रीन पर कॉपी किया जाता है। पैमाना बदलने से बस स्क्रीन निर्देशांक बदल जाएगा जिससे कैनवास में टेक्स्ट मैप किया गया है।

आह, यह समझ में आता है। यह दुर्भाग्यपूर्ण है, हालांकि निष्पक्ष होने के लिए मेरी समस्या अधिक है क्योंकि फोंट के ग्राफिकल प्रतिपादन को स्केल किए जाने के बाद धुंधला हो रहा है, लेकिन मैंने सोचा कि यह बेहतर प्रदर्शन भी होगा।

जबकि मैं सामान्य पाठ गुणवत्ता मुद्दों को ठीक करने के लिए इसे लागू करने के लिए उत्साहित हूं, मैं पूरी तरह से प्रदर्शन में सुधार करना चाहता हूं।

मेरे साथ इसके माध्यम से बात करने के लिए धन्यवाद।

@ सिल्वर-स्ट्रीक कोई समस्या नहीं। हालाँकि, WebGL में गुणवत्ता-प्रथम पाठ को लागू करना कठिन नहीं होना चाहिए। कुछ एप्लिकेशन अपने आप मेश बनाकर टेक्स्ट को लागू कर रहे हैं। आप फ़ॉन्ट फ़ाइल को पार्स कर सकते हैं, शीर्षों की सूची बना सकते हैं और उसे टेस्सेलेट कर सकते हैं। उन शिखरों को जाल के माध्यम से प्रस्तुत किया जा सकता है।

उच्च पैमाने पर, यह मामूली "किनारों" का कारण बन सकता है - क्योंकि आखिरकार, आप पाठ को त्रिकोण के रूप में प्रस्तुत कर रहे हैं। और भी उच्च गुणवत्ता के लिए, आप "सटीक बेजियर वक्र" शेडर का उपयोग कर सकते हैं जिसके बारे में मैं इस धागे में बात कर रहा था - यह वक्र को वक्र के रूप में प्रस्तुत करेगा न कि त्रिकोण।

अगर आपको टेक्स्ट क्वालिटी में मदद चाहिए, तो मैं आप लोगों की मदद कर सकता हूं :)

@SukantPal मैं निश्चित रूप से GDevelop में योगदानकर्ता नहीं हूं, (और न ही आप मुझे बनना चाहेंगे। मैं मुख्य रूप से एक बिजनेस सिस्टम एनालिस्ट/DevOps हूं, न कि डेवलपर 😄) हालांकि मुझे वह प्रोजेक्ट पसंद है और मैं समुदाय में सक्रिय हूं। . मुझे यह भी पता है कि समुदाय के अन्य सदस्य स्केल किए गए टेक्स्ट गुणवत्ता के समाधान को देखना पसंद करेंगे।

हालाँकि, यदि आप पोस्ट में इस मुद्दे पर एक नज़र डालना चाहते हैं, तो मेरे पास इसके लिए बाउंटीसोर्स पर एक इनाम भी है और यह सभी के लिए खुला है। मैं यहां और अधिक हेडस्पेस नहीं लेना चाहता, हालांकि, जैसा कि यह स्पष्ट है कि सामान्य रूप से पिक्सी के आसपास बहुत गहरी बातचीत चल रही है, और मेरा सुझाव उतना सटीक नहीं था जितना मैंने सोचा था।

@ सिल्वर-स्ट्रीक मैं देख सकता हूं, क्योंकि मेरे पास कोरोना-सीजन में करने के लिए कुछ भी बेहतर नहीं है

मुझे पता है कि यह एक बंद धागा है, लेकिन मुझे यकीन है कि हर कोई अभी भी टेक्स्ट रेंडरिंग को बेहतर बनाने का सबसे अच्छा तरीका ढूंढ रहा है। मैंने देखा है कि किसी के पास एक एमएसडीएफ कार्यान्वयन था जो पिक्सी v5 के साथ काम करता था। https://github.com/cjsjy123/pixi-msdf-text-v5 लगा कि मैं रुचि रखने वालों के लिए इसका उल्लेख करूंगा।

इस धागे को निश्चित रूप से फिर से खोला जाना चाहिए और जीवित रखा जाना चाहिए - या कम से कम हर बार किसी न किसी प्रकार का अपडेट होना चाहिए, क्योंकि यह सबसे अधिक देखी जाने वाली समस्याओं में से एक है।