Pixi.js: الاقتراح: تحسين عرض النص

لا ينبغي أن يكون في جوهره.
إنها حزمة ثقيلة ويجب تنفيذها خارج الحزمة الرئيسية ، ولا ينبغي للفريق الأساسي أن يقلق بشأن تنفيذها.

Pixi SDF هو المثال الصحيح.

من فضلك ، لا تحاول جعل Phaser من PIXI

أود إعطاء المزيد من السياق. لقد طلبت من SukantPal البحث عن نُهج Text / BitmapText بديلة لها مقايضات مختلفة. على وجه الخصوص ، إذا تمكنا من العثور على شيء يعمل بشكل أفضل من النص ويبدو رائعًا.

أعتقد أن هناك عددًا من الأساليب هنا. قد يكون بعضها مناسبًا كمكونات إضافية للجزء الثالث ، وبعضها قد يكون في الريبو ولكن ليس مجمّعًا ، والبعض قد يحل محل / يزيد من واجهة برمجة التطبيقات الحالية. دعنا نتعرف على نهج عرض النص الأكثر إثمارًا وهو تحسين الأداء ولكن مع مقايضة أقل مع BitmapText.

هناك بعض المعايير التي سأستخدمها للحكم على كائن عرض نص جيد:

• أداء جيد في وقت التشغيل - يعد عرض النص وتغيير النص منخفض التكلفة
• ذاكرة منخفضة - استخدام ذاكرة الوصول العشوائي منخفض
• التبعيات الصغيرة - حجم ملف بصمة التبعية صغير
• إخلاص رائع - يعمل بشكل جيد مع قرارات مختلفة
• تصميم مرن - دعم السكتات الدماغية والظلال المسقطة والتدرجات اللونية
• يدعم لغات الحروف الرسومية الكبيرة - على سبيل المثال ، الصينية ، اليابانية ، الكورية
• متوافق مع الإصدارات السابقة - يعمل مع Context2D

| | أداء | الذاكرة | التبعيات | الاخلاص | التصميم | CJK | Context2d |
| - | - | - | - | - | - | - | - |
| نص | 👎 | 👎 | 👍 | 👍 | 👍 | 👍 | 👍 | 👍 |
| نص نقطي | 👍 | 👎 | 👍 | 👎 | 👎 | 👎 | 👍 |

موافق.
لوصف fragment interpolation وجميع عمليات التنفيذ غير الأصلية:

1. يحتاج إلى مزيد من التظليل وبيانات إضافية - وهذا سيمنع التجميع.
2. يحتاج إعادة بناء الهندسة عند التغيير (ص 3).
3. تتطلب جدولًا رسوميًا لجميع الحروف الرسومية الموجودة في اللغة ، والتي تتطلب تحميل TTF محددًا إلى الذاكرة تمامًا ، لأن لا يمكن أن تدعم التدفق ، ثم تحليلها. يبدو وكأنه SWF.
   لأننا لا نستطيع تحميل خط النظام كشكل - لا يمكننا استخدامه.
4. يتم نقل قواعد اللغة المحددة إلى فريق lib من فريق المتصفح ، الذي ينفذ قواعد العرض: ltr / rtl ، قواعد تسلسل الحروف الرسومية الهندية / العربية ، إلخ ... نفس نقل متصفح 10٪ إلى lib. لم تكن الوحدة تنفذها بشكل صحيح حتى الآن.
5. تظليل ثقيل مع حجج إضافية لدعم الأنماط. يؤدي ذلك إلى زيادة تكلفة العرض ، لأنه يجب علينا عرضها في الوقت الفعلي.
   وبالطبع يجب أن نخفيه على هيئة نسيج.

تضمين التغريدة

• يمكن تجميع النص - ولكن ليس مع أشياء أخرى مثل الرسومات.

• يقوم تنفيذ النص الحالي بتخزين كل حرف رسومي مؤقتًا عدة مرات (إذا تم استخدام حرف عدة مرات عبر نصوص PIXI متعددة). من الأفضل وجود هندسة واحدة لكل حرف رسومي. أيضًا ، لا تحتاج إلى التخزين المؤقت بأحجام خطوط مختلفة.

• لا تحتاج الهندسة إلى إعادة بنائها لكل كلمة - إذا تغيرت الحروف في النص ، فأنت بحاجة إلى الجلب مرة أخرى من جدول هندسة الصورة الرمزية. إذا تغير التحويل ، فأنت تحتاج فقط إلى تغيير زي واحد.

• يمكننا استخدام مكتبة لتحليل الخط. التحول إلى الهندسة تافه.

• لا أعرف ما هي قواعد تسلسل الحروف الرسومية. هل يمكن ان توضح؟

• من اليسار إلى اليمين مقابل من اليمين إلى اليسار - إذا كنت تريد عكس الأحرف ، يمكنك ذلك. إذا كنت تريد صورة معكوسة ، فقم بتعيين scale.x=-1 داخليًا.

• لن يضيف نمط النص مزيدًا من الوسائط إلى التظليل. سوف يغير الهندسة. الآن ، تخزين الصورة الرمزية كشكل هندسي يأخذ ذاكرة _less_ من تخزينها مؤقتًا في نسيج.

• يجب تخزين ملفات الخطوط التي يتم جلبها من واجهات برمجة التطبيقات مؤقتًا على جهاز المستخدم.

أنت ساذج جدا:

1. يجب أن يكون مُجمِّعًا خارجيًا ، لأن الحروف الرسومية تتطلب سمة إضافية ، مثل مثبتات بيزير ، وقيم الظل ، ومثبتات التدرج ...
2. من اليمين إلى اليسار ومن اليسار إلى اليمين ، ومزجها مشكلة معقدة للغاية.
   المشكلات المفتوحة في عرض ملف PDF:
   https://github.com/asciidoctor/asciidoctor-pdf/issues/175
3. مشكلة هندية (ولغة مشابهة)
   https://docs.microsoft.com/en-us/typography/opentype/spec/gsub

لا يمكننا استخدام التبعيات الخارجية ، لأن المشكلة ستكون مثل isMobile أو resource-loader .
يجب أن تكون النواة نظيفة. الحد الأدنى من التبعيات الخارجية.

تضمين التغريدة

• التخطيط المختلط (ltr و rtl مجتمعين) أقل أولوية من الأداء العالي. يمكنك دائمًا الرجوع إلى الخوارزمية الحالية. مشابهة لـ Devanagari. ستحتاج الميزات الخاصة مثل نقاط توقف التدرج أيضًا إلى الرجوع.

• يمكن أن يعمل التجميع هنا لأنه سيكون أسهل بدون أي مواد. يمكن إنشاء مكون إضافي مثل CanvasGraphicsRenderer .

موافق. انت فوز. افعلها. لكن خارج النواة ، سننظر فيه ونقرر ما يجب أن نفعله بعد ذلك.
لكن بدون تبعيات ثقيلة.

eXponenta من فضلك توقف عن العدائية. نحن نستكشف طرقًا لا يوجد شيء صلب حتى الآن. من فضلك كن بناء ولا تستخدم الشتائم.

eXponenta هل أنت متأكد من أننا ندعم النص من اليمين إلى اليسار اعتبارًا من الآن؟

هناك طريقة أخرى نفكر فيها وهي تقديم كل صورة رمزية باستخدام Canvas 2D (كما هو الحال الآن) بشكل منفصل وتخزينها مؤقتًا في أطلس. يمكن إعادة استخدام الأطلس عالميًا لجميع حالات PIXI.Text . سيتم تخزين كل تركيبة glyph + font-size + font-style بشكل منفصل.

ما رأيك في قبول ذلك في جوهر؟

مرحبًا يا مختلسوا النظر ، من المثير حقًا سماع هذه الأساليب الجديدة على الطاولة. eXponenta ، مرددًا bigtimebuddy ،

في النص ، إليك سنتان (بنس؟) ..

أنا شخصياً أعتقد أن النهج الأكثر قيمة هو الحصول على سرعة وأداء نص الصورة النقطية ولكن دون الحاجة إلى إنشاء خط نقطي مسبقًا. بناء نسيج نقطي ديناميكي إذا صح التعبير!

خطوط نقطية ديناميكية

الايجابيات

• أدوات إنشاء خطوط نقطية قليلة ومتباعدة! أود إزالة هذا الحاجز.
• يمكننا إنشاء أحجام مختلفة من مواد حجم النص.
• يعمل مع كانفاس
• الأداء حيث يمكن تجميع كل حرف رسومي
• الكثير من التأثيرات الرائعة!
• ستحتاج API فقط إلى تعديل طفيف:

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


const bitmapFont = new BitmapFont(textStyle);

سلبيات

• جميع السلبيات الأخرى للخطوط النقطية الحالية للصور النقطية: P
• هل سيؤدي التحديث الديناميكي لأطلس القوام إلى إبطاء السرعة؟
  
  
  
  • على الرغم من أن هذا سيستقر بعد فترة ، وربما يمكن تخزينه مؤقتًا بين الجلسات؟
  
  
  • يجب أن يقوم النص الحالي أيضًا بتحميل مادة في كل مرة يغير فيها الإطار ، هل سيؤدي هذا النهج إلى تقليل ذلك؟
  
  

الأفكار

• هل يمكن تخزين الزخرفة في مخزن محلي مؤقتًا؟ للزيارات اللاحقة؟
• أضف الأحرف المستخدمة فقط ، لذا فإن الزخارف كبيرة بالقدر الذي يجب أن تكون عليه. التحديث كما نذهب
• قم بخبز المرشحات لهذا النسيج للحصول على تأثيرات رائعة إضافية (مخطط تفصيلي ، ظل ، إلخ)
• يمكننا expore تقليل ذاكرة الخط النقطي بعدم جعل كل صورة رمزية نقشًا؟

قسد
هل يمكن أن تكون قوات سوريا الديمقراطية امتدادًا للنهج المذكور أعلاه؟ ما مدى تعقيد إنشاء هذا النسيج ديناميكيًا؟ هل سيكون رائعًا جدًا؟ هل نتحدث عن زيادة قاعدة الشفرة بمقدار كبير؟

معظم الناس ليس لديهم فكرة عن ماهية ذلك ، لذا من الناحية المثالية يجب إخفاؤه. إذا احتجنا إلى إنشاء حقول SDF خارجيًا أو الرمز المطلوب للإنشاء كبير جدًا أو معقدًا ، فسيكون هذا أفضل في المنزل كمكوِّن إضافي بالتأكيد:

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);

عرض منحنى بيزير الدقيق

هذا نهج مثير للاهتمام بالتأكيد! لقد نظرت في هذا في الماضي وقررت أن مفاتيح التظليل التي تم إدخالها في حلقة التقديم والفسيفساء الإضافية المطلوبة سيكون لها حمل كبير. SukantPal ، أنت أقرب إلى هذه الفكرة مما أنا عليه الآن ، لذا أود أن تأخذ رأيك في

بعد قولي هذا ، ربما يكون من المفيد بناء نموذج أولي يمكننا اختباره والتغلب عليه قليلاً للتحقق من صحة تفكيرنا؟

أوقات مثيرة للنص: د

هل يمكن أن تكون قوات سوريا الديمقراطية امتدادًا للنهج المذكور أعلاه؟ ما مدى تعقيد إنشاء هذا النسيج ديناميكيًا؟ هل سيكون رائعًا جدًا؟ هل نتحدث عن زيادة قاعدة الشفرة بمقدار كبير؟

يعد إنشاء SDF مكلفًا ، وهناك وقت للتعبئة (عندما قمنا بحزم خطوط مختلفة في atlass) ، ولكن يمكن تخزينها مؤقتًا على العميل (مثل جميع المتغيرات الأخرى).
هناك قماش (الكالينجيون) تنفيذه:
https://github.com/mapbox/tiny-sdf
لكن تجميع SDF ليس صحيحًا تمامًا (تغيير الصورة الرمزية عند زيادة / تقليل حجم الخط)
يبدو مفيدًا ، لكن بالنسبة لـ MSDF ، يجب أن ننفذها 3 مرات (لكل قناة).

أوه ، واو ، هذا هو جزء صغير من التعليمات البرمجية! يبدو أنه قد حان لتظليل أن تفعله أيضا!

GoodBoyDigital تولد حزمة

لا ينبغي أن يكون إنشاء قناة SDF أحادية القناة سيئًا للغاية. إن SDF متعدد القنوات متفوق إلا أنه معقد للغاية. لم أستطع أن أفهم كيف كان Chumskly يشفر الزوايا.

الآن ، كل ما نفكر فيه لن يدعم تنسيق rtl و Ltr المختلط (كما أشار eXponenta بشكل صحيح). لكنني لا أعتقد أننا ندعمها رسميًا الآن أيضًا.

النهج الدقيق له فائدتان - حجم ذاكرة التخزين المؤقت الصغير (أنت تقوم بتخزين الرؤوس مؤقتًا وليس كل وحدات البكسل) ، ومقاومة الحواف حتى عند إيقاف تشغيل الإعداد "منع الحواف" (من المتوقع أن يكون النص غير متحيز دائمًا على ما أعتقد. التنفيذ الحالي يفعل ذلك باستخدام لوحة الرسم 2D).

بالنسبة للعرض التوضيحي ، هل ألقيت نظرة على العرض التوضيحي لمنحنى بيزير التربيعي؟ https://codepen.io/sukantpal/pen/GRJawBg؟editors=0010

——
شيء آخر ناقشته أنا و وتخزين الصور الرمزية في نسيج. يمكن تقديم الحروف الرسومية على شكل رباعي. يمكن إعادة استخدام أطلس ذاكرة التخزين المؤقت بين النصوص. بالطبع ، هذا يعني أنه يتم تخزين النص الكبير مؤقتًا بنفس الحجم وبالتالي استخدام ذاكرة كبيرة عندما يتم تقديم الكثير من النص ولكن جزء منه فقط (مثل الصفحة الحالية في PDF) يكون مرئيًا.

لطيف،

نعم ، لا داعي للقلق بشأن rtl أو ltr اللذان سيكونان متاحين دائمًا من خلال الطريقة الحالية وهي مشكلة ستحتاج جميع تقنيات عرض النص المخصص إلى حلها في تاريخ لاحق.
هذه القرارات. يجب أن تركز بشكل مثالي على استهلاك الذاكرة وأداء وقت التشغيل.

عرض Bezier رائع ، لكنني لا أشعر أنه كافٍ لفهم التعقيدات الحقيقية التي قد تختبئ إذا قدمنا ​​جملة كاملة.

الأشياء التي كتبتها عن الخطوط النقطية الديناميكية أعلاه هي إلى حد كبير ما ذكرته حول التخزين المؤقت للصور الرسومية. أعتقد أن هذا بالتأكيد طريق مفيد للنزول!

باختصار:

حلول منحنى بيزير: قد يكون هذا طريقًا جيدًا ، لكنني أشعر أن هذا يتطلب مزيدًا من البحث والتطوير لمعرفة كيف يتناسب مع حالات استخدام الإنتاج الحقيقية.

الخطوط النقطية الديناميكية من الخطوط العادية: يجب أن نستكشف هذا بالتأكيد كما نعلم أن هذا سيعطي أداءً جيدًا مع الحفاظ على واجهة برمجة التطبيقات بسيطة. المفضل لدي: د

قناة واحدة لقوات الدفاع الذاتى أقدر أنها لن تكون جيدة لقوات الدفاع الذاتى متعددة القنوات ، لكن العرض التوضيحي بدا جيدًا بالنسبة لي! إذا كان يمكن تغيير حجم النص بشكل جيد ويمكننا الحصول على نسيج واحد لكل خط ، فأعتقد أن هذا المسار قد يستحق التحقيق أيضًا!

GoodBoyDigital أعتقد أن العرض يحتوي على نص جيد جدًا. لكن هناك اختلافات واضحة إذا حاولت البحث عن التفاصيل:

النص الموجود في الأعلى ليس حادًا - الحواف بها اهتزازات. قد تحتاج مجموعات كل خط + (حوالي 12-15 بكسل في حجم الخط) إلى التخزين المؤقت بشكل منفصل.

أنا بخير تمامًا مع الذهاب إلى SDF إذا كانت هذه الاهتزازات غير مهمة أو إذا كان بإمكاننا استخدام التخزين المؤقت بأحجام خطوط متعددة.

أبسط حل هو أيضا جيد بالنسبة لي 💯tbh!

مرحبا جميعا.

أنا شخص عادي للغاية في كل ما يتعلق بـ Pixi ، لكنني مستخدم لـ GDevelop الذي يستخدم Pixi كخلفية لها ، ولقد كنت أتعمق في هذا الأمر لفترة من الوقت من أجل تنفيذ GDevelop لـ PixiJS وعرض النص. إنها في الواقع مؤثرة بالنسبة للعبة التي أعمل عليها وتحتوي على الكثير من النصوص. (يمكنك مشاهدة بحثي / أمثلة في المشكلة التي نشرتها في GDevelop: https://github.com/4ian/GDevelop/issues/1449)

ركز أحد الخيارات التي وجدتها على التجاهل التام لمشكلات التحجيم مع النص وإزالتها تمامًا من خلال ترك مقياس النص دائمًا عند 100٪ ، ولكن تغيير حجم خط النص بدلاً من ذلك؟ هذا حيادي الخط ، ويبدو أنه يعمل بجميع الأحجام.

إليك مثال على رمز حيث يتم ذلك باستخدام Pixi: https://codepen.io/Tazy/pen/wJVExB
لقد وجدته في هذا الموضوع: https://www.html5gamedevs.com/topic/29576-scalable-text-for-pixijs/

لدي بالفعل مكافأة بشأن هذه المشكلة لأنني كنت آمل أن يتمكن شخص ما من تعديل امتداد Pixi Text لـ GDevelop ، لكن (لكوني الشخص العادي الذي أنا عليه) لم أدرك أن هذه كانت مشكلة أكبر بكثير مع Pixi نفسها.

لا توجد فكرة عما إذا كانت هناك مشكلات محتملة في هذه الطريقة ، ولكن يبدو أنها تتجنب جميع مشكلات أداء sdf / msdf / إلخ.

@ Silver-Streak إذا كنت تقصد زيادة حجم الخط بالمقياس المطبق على كائن عرض النص ، فكيف يكون ذلك أفضل من حيث الأداء؟ تساعد عناصر SDF في الأداء لأنك لا تعيد العرض بأحجام خطوط أكبر.

@ Silver-Streak بالطبع ، سيحسن اقتراحك _quality_ لكني لا أرى كيف سيحسن الأداء.

@ Silver-Streak بالطبع ، سيحسن اقتراحك _quality_ لكني لا أرى كيف سيحسن الأداء.

ما لم أكن أفهم جيدًا ، ألا يستخدم تغيير حجم الخط موارد أقل من تغيير حجم الكائن بأكمله ، أو التحميل في عارض آخر؟ مرة أخرى ، أنا شخص عادي للغاية عندما يتعلق الأمر بكيفية عمل مقياس Pixi في الواقع ، كان من المنطقي بالنسبة لي أن ترك الخط بدقة أصلية ولكن مجرد تغيير حجم النص سيكون أسرع من قياسه. إذا كان هذا غير صحيح ، أعتذر عن الإلهاء.

@ تم تنفيذ مقياس Silver-Streak كتحويل. لديك مصفوفة تحويل - وتغيير المقياس في تلك المصفوفة عملية تافهة.

اعتبارًا من الآن ، يتم تقديم النص باستخدام Canvas 2D API في لوحة قماشية. ثم يتم نسخه على الشاشة. سيؤدي تغيير المقياس إلى تغيير إحداثيات الشاشة التي تم تعيين النص في اللوحة القماشية إليها.

آه ، هذا منطقي. هذا أمر مؤسف ، على الرغم من أن مشكلتي ، لكي نكون منصفين ، هي أكثر مع العرض الرسومي للخطوط الذي أصبح ضبابيًا بعد أن يتم تحجيمها ، لكنني اعتقدت أنه سيكون أداء أفضل أيضًا.

بينما سأكون متحمسًا لشخص ما لتنفيذه لإصلاح مشكلات جودة النص العامة ، يمكنني أن أفهم تمامًا الرغبة في تحسين الأداء أيضًا.

شكرا للتحدث معي من خلاله.

@ سيلفر ستريك لا مشكلة. ومع ذلك ، لا ينبغي أن يكون تنفيذ نص الجودة أولاً صعبًا في WebGL أيضًا. تقوم بعض التطبيقات بتنفيذ النص عن طريق إنشاء شبكة بمفردها. يمكنك تحليل ملف الخط وإنشاء قائمة بالرؤوس ووضعها بالفسيفساء. يمكن عرض هذه القمم من خلال شبكة.

في المقاييس العالية ، يمكن أن يتسبب هذا في ظهور "حواف" طفيفة - لأنك في النهاية تقوم بترجمة النص على هيئة مثلثات. للحصول على جودة أعلى ، يمكنك استخدام تظليل "منحنى بيزير الدقيق" الذي كنت أتحدث عنه في هذا الخيط - سيعرض المنحنيات على شكل منحنيات وليست مثلثات.

إذا كنت بحاجة إلى مساعدة في جودة النص ، يمكنني مساعدتك يا رفاق :)

SukantPal أنا بالتأكيد لست مساهمًا في GDevelop ، (ولا تريدني أن أكون. أنا في الغالب محلل أنظمة أعمال / DevOps في الحياة ، ولست مطورًا) على الرغم من أنني أحب هذا المشروع وأنا نشط في المجتمع . أعلم أيضًا أن هناك أعضاء آخرين في المجتمع يرغبون في رؤية حل لجودة النص المحسّن.

ومع ذلك ، إذا كنت ترغب في إلقاء نظرة على المشكلة في المنشور ، فلدي أيضًا مكافأة مقابل ذلك على Bountysource وكذلك مفتوحة للجميع. لا أريد أن أتناول أي فراغ إضافي هنا ، على الرغم من أنه من الواضح أن هناك محادثة أعمق تدور حول Pixi بشكل عام ، ولم يكن اقتراحي في المكان المناسب كما كنت أعتقد.

@ Silver-Streak قد ألقي نظرة ، لأنني لا أملك شيئًا أفضل لأفعله في موسم كورونا

أعلم أن هذا خيط مغلق ، لكنني متأكد من أن الجميع ما زال يبحث عن أفضل طريقة لتحسين عرض النص. لقد لاحظت أن شخصًا ما لديه تطبيق msdf يعمل مع Pixi v5. https://github.com/cjsjy123/pixi-msdf-text-v5 أحسب أن أذكره للمهتمين.

يجب بالتأكيد إعادة فتح هذا الموضوع وإبقائه على قيد الحياة - أو على الأقل إجراء تحديث ما بين الحين والآخر ، لأن هذا هو أحد أكثر المشكلات التي يتم البحث عنها.