Troika: [troika-three-text] مشكلات تحميل IOS Safari

شكرا على الإبلاغ عن هذا! أنت لست أول من وصف مثل هذه المشكلات في iOS Safari ، لكنني لم أتمكن من إعادة إنتاجها سابقًا. سأحاول مع موقعك وآمل أن أتمكن من إعادة إنتاجه.

هل تستخدمه عن طريق drei بالصدفة؟ أم مباشرة؟

مرحبًا lojjic ، أنا أستخدم هذه الحزمة مباشرة مع three.js. والسبب في امتلاك ثلاث أدوات هو أنني أستخدم أيضًا وظيفة createDerivedMaterial الخاصة بك في بعض الحالات.

شكرا للتحقق من هذا!

لقد تمكنت من إعادة إظهار المشكلة (المشكلات) في تحميل موقع الويب الخاص بك على جهاز iPhone 8. لم يتح لي الوقت بعد لبدء تصحيح الأخطاء ولكني أردت فقط الإقرار بأن الخطأ قابل للتكرار.

atlmtwlojjic واجهت نفس المشكلة في Safari في مشروع كان يستخدم خطوطًا متعددة. كان الإصلاح الوحيد الذي وجدته هو استخدام خط فريد على موقع الويب بالكامل لهذا المتصفح.

+1
خطوط متعددة في كل مشهد = بعض الخطوط لا تظهر أبدًا على iPhone X و iphone SE

أحاول التعمق في هذه المشكلة ، وأواجه مشكلة في إعادة إنتاجها الآن. iPhone 8 نفسه كما كان من قبل. لا يمكنني إعادة إنتاجه على موقع designdalena.com بعد الآن ، ولكن من المحتمل أن هذا الموقع قد تغير بحيث لم يعد يستخدم نص ثلاثي ثلاثي الأبعاد أو يعمل حوله بطريقة أخرى.

لذلك أحاول إنشاء نموذج اختبار بسيط باستخدام خطوط متعددة ، ولا يمكنني جعلها تفشل:

https://uqgxq.csb.app/

هل يستطيع أي شخص آخر إعادة إنتاج هذا في مكان ما يمكنني استخدامه للاختبار / التصحيح؟

يا lojjic

للتأكيد ، قمت بالتبديل إلى شيء آخر. على الرغم من أنني أستمتع بتجربة استخدام الترويكا أكثر.

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

ياlojjic
أي حظ مع هذا؟ لقد رأيت هذا أيضًا عند استخدام> 1 خط ، على iPhone (يعمل على iPad و macOS). من الغريب أن هذا غير قابل للتكرار طوال الوقت ، يحدث فقط 1-2 / 10 مرات وفقط عند التحميل الأول. ربما تتعلق تنزيلات ملف الخط؟

بالمناسبة ، أحب العمل: 100:

@ amitrajput1992 لا ما زلت غير قادر على تكوين حالة اختبار قابلة للتكرار. هل لديك واحدة يمكنني استخدامها؟

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

هذا ما أراه على BrowserStack. هذا موجود على Iphone 8 + Safari v13

هذا واحد على جهاز iPhone 11 + Safari 14

هل يمكن أن يكون له علاقة بحقيقة أن ملفات الخطوط يتم تنزيلها في عامل الويب؟ نحن نعلم أن رحلات السفاري يمكن أن تكون مصدر إزعاج للعاملين على الويب

@ amitrajput1992 شكرًا ، يمكنني بالفعل تكرار المشكلة على تلك الصفحة. سأرى ما إذا كان بإمكاني تصحيح الأخطاء من هناك و / أو تكرارها في حقيبة اختبار محلية مصغرة.

نحن نعلم أن رحلات السفاري يمكن أن تكون مصدر إزعاج للعاملين على الويب

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

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

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

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

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

أعتقد أنني يجب أن أركز أولاً على هذه القطع الأثرية ، التي لا تظهر دائمًا ولكنها تظهر أحيانًا:

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

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

سأحقق في ذلك كاحتمال (ربما يعطي XHR استجابة جزئية للمصفوفة؟) ولكن الخطوة الأولى هي إدخال هذا في حقيبة اختبار قابلة للتكرار يمكنني تعديلها وتشغيلها محليًا.

منطقي. يمكن أن يكون فساد arraybuffer الجاني هنا.
رأيت مناقشة أخرى حول جعل هذه العملية برمتها تعمل على الموضوع الرئيسي. هل هذا على خارطة الطريق؟

أيضًا ، إذا كان ذلك مفيدًا ، فأنا أستخدم الترويكا باستخدام drei مع الإصدارات التالية:
@ رد فعل ثلاثة / الألياف: 6.2.3
@ رد فعل ثلاثة / دري: 6.0.1
الترويكا: 0.42.0
ثلاثة: 0.129.0

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

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

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

من المزعج معرفة أن هذا لا يزال يحدث مع خط واحد أيضًا: نخيل الوجه:

حسنًا ، يبدو أنه لا يمكنني الحصول على الخطأ الذي يحدث مع الخط الفردي الجديد إلا عند الاتصال بـ Safari devtools ، وقد تم التنصت عليه باستمرار. لست متأكدًا مما إذا كان ذلك يعطينا أي دليل أم لا.

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

في كلتا الحالتين ، أواجه مشكلة في عدم تمكن أدوات تطوير اتصال USB في Safari من تعيين نقاط التوقف في الكود ذي الصلة. @ amitrajput1992 هل سيكون من الممكن الحصول على تطبيقك الاختباري كملفات مصدر يمكنني إنشاؤها / تشغيلها محليًا ، لذا يمكنني محاولة تبديل رمز الترويكا للتصحيح؟

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

تضمين التغريدة
لقد قمت بإعداد نسخة أساسية بهيكل مماثل لتطبيق الإنتاج الخاص بي هنا: https://github.com/amitrajput1992/r3f-experiments
يمكنني تكرار نفس المشكلة مع هذا على iPhone 11 الخاص بي وعلى BrowserStack.
تم نشر كتاب القصة هنا أيضًا لسهولة الوصول إليه https://amitrajput1992.github.io/r3f-experiments

@ amitrajput1992 شكرا على testcase! يمكنني تكرارها هناك بعد إصلاح أخطاء CORS ، وتحميل الخطوط من موقع gmetri الخاص بك عن طريق تقديمها من كتاب القصة.

ومع ذلك ... فإن أدوات تطوير Safari الخاصة بي ممتلئة بالأعطال التي تحاول الاتصال بها! 🤦🤦🤦🤦🤦🤦 لذلك لا يمكنني حتى إضافة بيانات console.log ورؤيتها. هذا الخطأ لا يريد حقًا إصلاحه ، أليس كذلك؟

الشعور بالإحباط سأحاول العودة إلى هذا بعقل أعذب غدًا. اعلمني ان كانت لديك اي فكرة.

مرحبًا lojjic ، ليس لدي نظام mac معي حاليًا ، لكنني اختبرت هذا على browserstack مع إعادة التوجيه المحلي. يبدو أن بيانات sdf التي تم تسجيلها داخل Web-worker مقابل مؤشر الترابط الرئيسي مختلفة. قد يكون راجعا إلى عملية التسلسل وإلغاء التسلسل بين اتصالات الخيط ، ولكن ليس متأكدا تماما. سأستمر في تصحيح هذا الأمر أكثر.
يمكنك تجربة الاختبار المتقاطع إذا كانت أدوات تطوير Safari لا تعمل من أجلك ، فهي توفر نسخة تجريبية مدتها 100 دقيقة والتي قد تكون مفيدة.

عدم القدرة على تعيين نقاط التوقف في الكود ذي الصلة

اقتراح غبي لرمي رسالة من عامل الويب بعد كل سطر من التعليمات البرمجية و console.log ، لأنكم يا رفاق قادرون على إعادة إنتاج الخطأ.

صورة على جهاز iPhone 6/11 الخاص بي:

اقتراح غبي لرمي رسالة من webworker بعد كل سطر من التعليمات البرمجية و console.log

ليس اقتراح غبي على الإطلاق! وهذا بالضبط ما كنت أحاول القيام به ، لكن أدوات التطوير في Safari تتعطل على الفور بالنسبة لي عند الإشارة إلى مثيل محلي قابل للتحرير ، لذلك لا يمكنني حتى رؤية إخراج console.log. :(

هل تحاول فتح عنوان url المضيف المحلي في iPhone المتصل؟ كيف يعمل ميناء الشحن في هذه الحالة؟

هل تحاول فتح عنوان url المضيف المحلي في iPhone المتصل؟ كيف يعمل ميناء الشحن في هذه الحالة؟

أقوم بالوصول إلى خادم dev من iPhone عبر عنوان IP للشبكة المحلية. لقد حاولت أيضًا توصيله عبر https://localhost.run. في كلتا الحالتين ، يتعطل Safari devtools بمجرد فتحه. يتم عرض الصفحة نفسها بشكل جيد (على الرغم من وجود الخطأ في بعض الأحيان.)

قرأت في بعض المدونات أن هذا يمكن أن يحدث في سيناريوهين:

1. عندما تكون بطارية الهاتف على 100٪
2. عند التصحيح عبر الشبكة وليس اتصال الكابل

هذا خيط طويل المدى على خطوط متشابهة ، لكن لا يوجد دقة https://developer.apple.com/forums/thread/92290

لكن أدوات التطوير في Safari تتعطل على الفور بالنسبة لي عند الإشارة إلى مثيل محلي قابل للتحرير ، لذلك لا يمكنني حتى رؤية إخراج console.log. :(

من الممكن استبدال وظيفة console.log الافتراضية بشيء من هذا القبيل

console.log = (msg) => document.getElementById("my_ios_console").innerHTML += msg;

لكنك تحتاج إلى إنشاء هذا div على صفحة html أو من برنامج JS script

<div id="my_ios_console" style="position: absolute; top:0; left: 0; background: white"></div>

يجب أن يُظهر هذا جميع رسائل وحدة التحكم في الموضوع الرئيسي

شكرًا unrocket ، قد ينجح ذلك ، سأجربه.

مرحبا جميعا،

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

lojjic أي حظ في هذا؟

أي حظ مع هذا؟

لا ، للأسف ، لم أتمكن من تخصيص الكثير من الوقت لهذا مؤخرًا.

هل هناك أي إمكانية لإيقاف تشغيل العاملين على الويب؟ فقط للتحقق

مرحبا بالجميع،

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

قبل أن أذهب إلى أبعد من ذلك ، أود أن أوضح أن المعلومات والتعديل أدناه لا ينصح بهما بأي شكل من الأشكال ، ويتم مشاركتها هنا فقط للمساعدة في البحث عن حل حقيقي. المعلومات الواردة أدناه ليست حلا. لقد تم تحذيرك.

أولا. نعم ، كما ذكرنا سابقًا في المناقشة ، يبدو أن هذا هو بالفعل خطأ WebWorker في iOS Safari على وجه التحديد. لا يقدم Firefox (win10) و Chrome (win10) و Opera (win10) و Safari (macOS big sur) وآخرون هذه المشكلة ويتم تحميل الخطوط بشكل صحيح بنسبة 100٪ من الوقت. ومع ذلك ، فإن Safari (iOS) يواجه نوعًا من حالة السباق بين العديد من WebWorkers (لم أحدد ما إذا كان هذا صحيحًا تمامًا ولا المكالمات غير المتزامنة التي تتداخل مع بعضها البعض).

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

ثالث. بعد تحديد الموقع الدقيق الذي أحتاجه (هذه الوظيفة readShort في Typr / bin.s ) ، قمت بتعديلها بعدة طرق لفهم ما يجري.

        readShort : function(buff, p)
    {
        //if(p>=buff.length) throw "error";
        var a = Typr._bin.t.uint8;
        a[1] = buff[p]; a[0] = buff[p+1];
        return Typr._bin.t.int16[0];
    },

عندما كنت ببساطة أستخدم console.log (Typr._bin.t.int16 [0]) ، سيطبع التطبيق عددًا قليلاً من NaN لا ينبغي أبدًا أن يكون (جرب ذلك بحذر لأن التطبيق بأكمله قد يتعطل مواد الطباعة - تسمى هذه الوظيفة آلاف المرات حسب حالة الاستخدام). ومع ذلك ، كما هو متوقع ، يؤدي إيقاف التطبيق مؤقتًا في أي مكان داخل هذه الوظيفة (باستخدام كلمة رئيسية لمصحح الأخطاء أو نقطة توقف أو حتى الوصول إلى وحدة التحكم) إلى تصحيح القيمة نفسها وعدم إنتاج NaN (مما دفعني إلى الاعتقاد بحالة السباق). هذا يعني أنه لا يمكنك فحص المشكلة باستخدام مصحح أخطاء بالطرق التقليدية.

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

if (Number.isNaN(Typr._bin.t.int16[0])) {
    console.log()
}

وقد نجحت! يظهر الآن كل النص بشكل جيد في iOS Safari وكذلك جميع المتصفحات الأخرى التي اختبرتها من قبل. تم حل المشكلة ~ ... كيندا ، بأسوأ طريقة ممكنة. اتضح أن الإطار المختصر الذي ينشئه التطبيق للوصول إلى وحدة التحكم يحل حالة السباق المزعومة. ولاحظ أنه لا يفعل ذلك إلا عند توصيله بوحدة التحكم.

ختاما. هذا هو المكان الذي أنا فيه. يعمل الحل الرهيب ، لكني ما زلت أبحث عن حل فعلي لهذا الأمر تمامًا كما يجب على الجميع هنا أيضًا. اتضح أن المشكلة قد تكون أو لا تكون في Troika ، لأنها ربما كانت في Typr طوال الوقت ، أو حتى تطبيق iOS لـ WebWorker (من يدري). على أي حال ، آمل أن تساعد كل هذه المعلومات في التحقيق ونرى جميعًا هذه المعلومات حتى النهاية.

مكدس الاستدعاء المرجعي:
Typr / bin.js - readShort
Typr / glyf.js - _parseGlyf
Typr / Typr.U.js - _drawGlyf
Typr / Typr.U.js - glyphToPath
Troika / FontParser_Typr.js - (مجهول) forEachGlyph
Troika / FontParser_Typr.js - wrapFontObj
Troika / FontParser_Typr.js - تحليل
... عامل الاشياء

و lojjic ، بخصوص استكشاف أخطاء iOS Safari وإصلاحها عبر USB باستخدام MacOS Safari:
أنصح بمحاولة قطع الاتصال وإعادة الاتصال بالشبكة المحلية أو هاتفك إذا أصر MacOS Safari DevTools على التحميل إلى أجل غير مسمى أو عرض رسالة تفيد بأن الصفحة تعطلت أو لا يتم تحميل البرامج النصية أو لا. إما ذلك ، أو حاول إغلاق DevTools وإعادة فتحه عدة مرات. ثم تحديث صفحة الويب على الهاتف بشكل واضح. أقول هذا لأن هذا حدث لي اليوم عدة مرات (ألم) وقمت بحله بهذه الطريقة (الاتصال بين MacOS Big Sur و iOS 15.0.1).

OMGmalulleybovo عدت من الإجازة وشاهدت النتائج التي توصلت إليها وكانت مفاجأة رائعة! 😃 شكرًا جزيلاً على التعمق في هذا الأمر.

مجرد معرفة أن readShort ينتج NaN هو خطوة كبيرة إلى الأمام ربما في فهم هذه المشكلة أخيرًا ، والتي كما تعلم كنت عالقًا تمامًا لبعض الوقت. لم يساعدني ذلك في تغيير الوظائف وفقدت الوصول إلى جهاز iOS الذي كنت أستخدمه.

سيكون سؤالي التالي هل يمكننا تحديد _لماذا_ قراءة Typr._bin.t.int16 [0] تنتج NaN؟ يبدو أنه يجب الحصول على قيمة غير صحيحة في أحد المخازن المؤقتة (إما قيمة الخط buff أو الأداة المساعدة Typr._bin.t.buff ) ، ولكن من المفيد معرفة قيم Buff / uint8 / int16 بالضبط في تلك المرحلة الزمنية مقابل ما ينبغي أن يكونوا عليه.

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

lojjic تهانينا على تغيير الوظيفة!

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

        readShort : function(buff, p)
    {
        //if(p>=buff.length) throw "error";
        var a = Typr._bin.t.uint8;
        a[1] = buff[p]; a[0] = buff[p+1];
        /***** Right here, I peeked at Typr._bin.t.int16, Typr._bin.t.int8, and Typr._bin.t.uint8 ******/
        return Typr._bin.t.int16[0];
    },

أثناء إلقاء نظرة خاطفة على أول ظهور لـ NaN في readShort داخل تطبيقي ، اكتشفت أن Buff [p] = 255 و buff [p + 1] = 6 (كلاهما قيمتان صالحتان uint8). مع وضع ذلك في الاعتبار ، ألقيت نظرة خاطفة على قيم Typr._bin.t.uint8 ووجدت أنها تحتوي على [6 ، 255 ، 0 ، ...] كما هو متوقع. ثم ألقيت نظرة خاطفة على Typr._bin.t.int16 ووجدت الخطأ [NaN ، 0 ، ...] بدلاً من [-250 ، 0 ، ...]. أخيرًا ، ألقيت نظرة خاطفة على Typr._bin.t.int8 و ... كانت أيضًا خاطئة ... كانت [6 ، NaN ، 0 ، ...] بدلاً من [6 ، -1 ، 0 ، ...] .

تستخدم مكتبة Typr glyf ArrayBuffer واحدًا مشتركًا على مصفوفات متعددة من نوع مختلف (Uint8Array و Int8Array و Int16Array وما إلى ذلك). أظهر لي هذا التكرار أنه في iOS Safari (فقط) ، بعد تغيير إحدى هذه المصفوفات ، قد لا يتم تحديث القيم الموجودة في الآخرين على الفور. لا يوجد دليل على السبب ، لكنني وجدت تقرير خطأ تم حله يتضمن ArrayBuffer في iOS Safari في التاريخ الحديث مما يجعل هذا أكثر تصديقًا ... ثبت أنه معيب مرة واحدة ، وقد يثبت أنه معيب مرتين (المرجع: (https: //bugs.webkit .org / show_bug.cgi؟ id = 194268) [https://bugs.webkit.org/show_bug.cgi؟id=194268]).

بعد الكشف عن هذا ، قررت تجربة تنفيذ بديل للتحويل (uint8,uint8) to int16 . هذه المرة باستخدام العمليات الأحادية. الكود الذي استخدمته هو كالتالي:

        readShort : function(buff, p)
    {
        var a = buff[p + 1] + (buff[p] << 8);
        if (a > 0b0111111111111111) {
            a = (~a) + 1;
        }
        a = (a < 0 ? -1 : 1) * (a & 0b1111111111111111);
        return a;
    },

وهناك لديك. يظهر الآن كل النص الذي يحتوي على الخط بشكل صحيح دائمًا (حتى بدون الاتصال بـ devtools - ارجع إلى تعليقي السابق حول شيء console.log لفهم إخلاء المسؤولية هذا) حل هذا الحل البديل المشكلة في iOS Safari (تم اختباره على iOS 15.0.2) ، ويستمر في العمل في المتصفحات السابقة التي اختبرت عليها من قبل تمامًا كما فعلت من قبل ، مثل Chrome v95.0.4638.54 (win10) و Firefox v93.0 (win10) و Opera v80.0.4170.63 (win10) و MacOS Safari (MacOS Big Sur v11.3.1).

* إذا كان بإمكان أي شخص تحسين مقتطف الشفرة أعلاه ، فلا تتردد ~

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

أعتقد أن malulleybovo يستحق جائزة أو شيء من هذا القبيل! 🥳

هذا أمر مذهل ، حيث يتم تضييقه والتوصل إلى تطبيق بديل يتجنب المشكلة! شكرا جزيلا لك!

يسعدني دمج حل readShort الخاص بك ، كتجاوز محلي في الترويكا و / أو المنبع في Typr. قد نريد تطبيقات بديلة لطرق readFoo الأخرى أيضًا؟

يبدو أن هناك شيئًا خاطئًا / خطيرًا في نمط مشاركة المصفوفات المكتوبة في المخزن المؤقت بشكل عام. إنه نمط مثير للفضول الآن بعد أن أفكر فيه. يبدو أن الغرض من DataView هو قراءة تنسيقات الأرقام المختلفة من النظام الثنائي ، دون أي تحويل غريب للقيمة بين أرقام uints و JS أو تناقضات endianness ... أتساءل عما إذا كان ذلك سيحل المشكلة أيضًا؟ شيء من هذا القبيل ربما؟ https://gist.github.com/lojjic/94d7b5f5f374598fe0e9761be45ebb2b

شكرًا على الإطراء @ lojjic ~ أنا سعيد لأنني كنت مفيدًا.

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

يعتمد تطبيقي على البرنامج النصي glyf الخاص بـ Typr ، والذي يستخدم readInt8 من Typr و readShort و readUshort و readBytes. على الرغم من أنني قمت بتضمين الحل الكامل الخاص بك لأغراض الاختبار ، فقد اختبرته فقط على هذه الوظائف. وكل شيء يعمل بمظهره.

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

أعتقد أن readFixed ، و readF2dot14 ، و readUshorts ، و readUint64 ، و readASCII ، و readUnicode ، و readUTF8 ، و readBytes ، و readASCIIArray from bin.js ، بحاجة إلى تغيير لأنهم لا يستخدمون المصفوفات المكتوبة مباشرةً. لذلك فإن الوظائف الموجودة في جوهرها فقط هي التي ستحتاج إلى تغيير داخل Typr. بالإضافة إلى ذلك ، إلى جانب هذا التغيير ، ستصبح المصفوفات المكتوبة والمصفوفة المكتوبة من Typr عفا عليها الزمن.

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

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

مدهش!!! لا أستطيع أن أصدق ذلك. 🎉 🥳

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

يبدو الأداء قابلاً للمقارنة ، حتى أنه أسرع قليلاً في بعض الحالات. فوز إضافي! 😄

لقد تحققت من أن الوظائف الأخرى تعمل أيضًا. اضطررت إلى تعديل المساعد _view قليلاً للتعامل مع الحالات في خطوط CFF حيث يمرر Typr buff كمصفوفة JS عادية بدلاً من Uint8Array.

لقد قمت بنشر إصدار اختبار ثلاثي ثلاثي الأبعاد 0.43.1-alpha.0 مع إصلاح DataView فيه (حاليًا باستخدام مفترق خاص لـ Typr - الالتزام ذي الصلة )

أي شخص قادر (@ amitrajput1992؟strangerintheq؟atlmtw؟) ، سأكون ممتنًا للغاية لاختبار هذا الإصدار للتحقق من أنه يصلح المشكلة في تطبيقاتك المحددة. سأحاول أن أفعل الشيء نفسه إما مع Browserstack أو العثور على iPhone للاستعارة. شكرا مقدما!

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

@ amitrajput1992 مرحبًا ، هل سنحت لك فرصة اختبار ألفا حتى الآن؟ أرغب في الحصول على هذا الإصدار وسأحب التحقق الإضافي من الصحة. :)

lojjic مرحبًا ، لقد حصلت للتو على الوقت لاختبار ذلك. يبدو أنه يعمل الآن !!

تحقق من التغييرات هنا: https://amitrajput1992.github.io/r3f-experiments/؟path=/story/testers --text-tester

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