Troika: [troika-three-text] IOS Safari Memuat Masalah

Terima kasih telah melaporkan ini! Anda bukan orang pertama yang menjelaskan masalah seperti ini di Safari iOS, tetapi saya tidak dapat mereproduksinya sebelumnya. Saya akan mencoba dengan situs Anda dan mudah-mudahan saya dapat mereproduksinya.

Apakah Anda menggunakannya melalui drei secara kebetulan? Atau langsung?

Hai @lojjic Saya menggunakan paket ini langsung dengan three.js. Dan alasan saya memiliki tiga util adalah karena saya juga menggunakan fungsi createDerivedMaterial Anda dalam beberapa kasus.

Terima kasih telah memeriksa ini!

Saya dapat mereproduksi masalah saat memuat situs web Anda di iPhone 8. Saya belum punya waktu untuk memulai debugging tetapi saya hanya ingin mengakui bahwa bug tersebut dapat direproduksi.

@atlmtw @lojjic Saya memiliki masalah yang sama pada safari pada proyek yang menggunakan banyak font. Satu-satunya perbaikan yang saya temukan adalah menggunakan font unik di seluruh situs web untuk browser ini.

+1
beberapa font per adegan = beberapa font tidak pernah muncul di iphone X, iphone SE

Saya mencoba menggali masalah ini, dan saya kesulitan mereproduksinya sekarang. iPhone 8 yang sama seperti sebelumnya. Saya tidak dapat mereproduksinya di designdalena.com lagi, tetapi mungkin situs tersebut telah berubah untuk tidak lagi menggunakan troika-three-text atau mengatasinya dengan cara lain.

Jadi saya mencoba membuat testcase minimal menggunakan banyak font, dan tidak bisa gagal:

https://uqgxq.csb.app/

Adakah orang lain yang dapat mereproduksi ini di suatu tempat yang dapat saya gunakan untuk menguji/men-debug?

Hai @lojjic

Untuk mengonfirmasi, saya memang beralih ke sesuatu yang lain. Meskipun saya lebih menikmati pengalaman menggunakan troika.

@atlmtw Terima kasih atas konfirmasinya. Saya kira Anda tidak memiliki versi lama situs Anda di kontrol sumber yang dapat Anda kirimkan kepada saya? Saya berjuang untuk mereproduksi ini dan milik Anda tampak seperti repro yang andal.

Hai @lojjic
Adakah keberuntungan dengan ini? Saya telah melihat ini juga ketika> 1 font digunakan, di iPhone (berfungsi di iPad dan macOS). Anehnya ini tidak dapat direplikasi sepanjang waktu, hanya terjadi 1-2/10 kali dan hanya pada beban pertama. Terkait dengan unduhan file font mungkin?

Btw, suka pekerjaannya :100:

@amitrajput1992 Tidak, saya masih belum dapat membuat kasus uji yang dapat direproduksi. Apakah Anda punya satu yang bisa saya gunakan?

@lojjic
Coba ini ?
Jika Anda membuka di desktop, Anda akan melihat 6 teks berbeda yang dicetak dengan warna berbeda.
Saya menguji tautan ini di beberapa perangkat dengan saya dan beberapa di BrowserStack, semuanya menunjukkan masalah rendering. Menyegarkan tautan beberapa kali membuatnya berfungsi, yang sangat aneh.

Inilah yang saya lihat di BrowserStack. Ini ada di Iphone 8 + Safari v13

Yang ini di iPhone 11 + Safari 14 saya

Mungkinkah ada hubungannya dengan fakta bahwa file font diunduh di web-worker? Kami tahu safari bisa menyusahkan pekerja web

@amitrajput1992 Terima kasih, saya memang bisa mereplikasi masalah di halaman itu. Saya akan melihat apakah saya dapat men-debug dari sana dan/atau mereplikasinya dalam testcase lokal yang diperkecil.

Kami tahu safari bisa menyusahkan pekerja web

Saya pernah mendengar orang lain mengatakan ini juga, dan penggunaan pekerja jelas merupakan penyebab yang masuk akal, tetapi saya belum dapat menemukan detail tentang bug yang diketahui dengan pekerja di Safari. Apakah Anda memiliki spesifik di sana yang dapat Anda bagikan?

@lojjic
Boleh juga. Beri tahu saya jika saya dapat membantu dengan cara apa pun. Sementara itu, saya akan terus men-debug dan mencoba mempersempit masalah di pihak saya juga.

Saya pernah mendengar orang lain mengatakan ini juga, dan penggunaan pekerja jelas merupakan penyebab yang masuk akal, tetapi saya belum dapat menemukan detail tentang bug yang diketahui dengan pekerja di Safari. Apakah Anda memiliki spesifik di sana yang dapat Anda bagikan?

Saya tidak tahu tentang masalah sebenarnya di sini, sebagian karena saya tidak dapat menemukannya di mana pun (atau orang tidak mencatatnya), tetapi ini adalah sesuatu yang saya perhatikan saat bermain-main. react360 sebelumnya react-vr (ditinggalkan sekarang) digunakan untuk menjalankan seluruh kode reaksi di dalam pekerja web dan pembaruan ke utas utama terlalu lambat. Ini akan dengan mudah mengambil tindakan klik di mana saja sekitar 300 md hingga 500 md untuk disebarkan ke pendengar klik saya di utas pekerja dan sering kali juga akan kehilangan beberapa klik.
Saya memelihara repo yang merupakan penyaji gif untuk tiga orang, awalnya mencoba dengan kanvas di luar layar tetapi hasilnya mengerikan dan menghasilkan perpaduan tekstur pada bingkai yang berurutan. Memindahkan semuanya ke utas utama meningkatkannya secara drastis.

Saya merasa ini mungkin ada hubungannya dengan algoritma kloning terstruktur yang digunakan saat mengirimkan informasi dari pekerja ke utas utama. Meskipun saya belum dapat menemukan bukti kuat seputar batasan ini di iOS

Saya pikir saya harus terlebih dahulu fokus pada artefak ini, yang tidak selalu muncul tetapi terkadang muncul:

Dalam kasus tersebut, tata letak dan pembuatan SDF jelas selesai dan kembali ke utas utama, tetapi beberapa SDF tampaknya memiliki isian di dalam/luar yang terbalik di beberapa tempat. Saya bisa melihat bagaimana itu bisa terjadi jika data jalur untuk karakter tersebut tidak lengkap, seperti hanya memiliki setengah segmen jalurnya.

Jika sesuatu terjadi selama pemuatan font di mana arraybuffer font terpotong atau rusak, saya pikir itu mungkin dapat menyebabkan gejala yang diamati ini. Demikian juga itu juga bisa menghasilkan hasil yang benar-benar kosong jika terpotong di tempat-tempat tertentu.

Saya akan menyelidikinya sebagai kemungkinan (mungkin XHR memberikan respons arraybuffer parsial?) tetapi langkah pertama adalah memasukkan ini ke dalam testcase yang dapat direproduksi yang dapat saya modifikasi dan jalankan secara lokal.

Itu masuk akal. korupsi arraybuffer bisa menjadi penyebab di sini.
Saya melihat diskusi lain tentang membuat seluruh proses ini berjalan di utas utama. Apakah itu ada di peta jalan?

Juga, Jika membantu, saya menggunakan troika menggunakan drei dengan versi di bawah ini:
@react-three/fiber: 6.2.3
@react-three/drei: 6.0.1
troika: 0.42.0
tiga: 0.129.0

Berjalan di utas utama dimungkinkan, tetapi akan menghasilkan pengalaman yang cukup buruk memblokir utas utama selama beberapa detik. Itu harus menjadi pilihan terakhir saja.

Apakah halaman pengujian Anda berubah? Sepertinya hanya menggunakan satu font untuk semua objek teks yang berbeda sekarang, setidaknya di iOS...? Saya masih melihat SDF yang kacau dengan font tunggal itu kadang-kadang, yang menyiratkan ini dapat diperburuk oleh banyak font tetapi tidak terbatas pada itu.

Saya memang menambahkan fallback untuk perangkat iOS untuk hanya menggunakan satu font untuk seluruh aplikasi. Ini adalah env produksi saya, jadi tidak ada barang yang rusak di sana.
Saya akan membuat contoh lain di env pementasan saya dan mengirimkan tautan di sini secepatnya.

Sulit untuk mengetahui bahwa ini masih terjadi dengan satu font juga :facepalm:

Hmm sepertinya saya hanya bisa membuat bug terjadi dengan font tunggal baru Anda saat terhubung ke Safari devtools, dan itu cukup disadap secara konsisten. Tidak yakin apakah itu memberi kita petunjuk atau tidak.

Nah, sedikit kemajuan lagi... Saya telah memverifikasi bahwa saya dapat memaksa artefak mesin terbang parsial yang sama seperti yang terlihat di atas dengan memotong perintah jalur untuk mesin terbang individu. Saya belum dapat menentukan apakah itu karena data font asli tidak lengkap (saya pikir itu hanya akan menyebabkan satu mesin terbang parsial, tidak banyak, jadi sepertinya tidak mungkin), atau jika ada sesuatu yang menyebabkan for-loop keluar lebih awal (ini tampaknya tidak mungkin, tapi mungkin ada beberapa bug JIT yang aneh).

Either way, saya terjebak dengan devtools koneksi USB Safari tidak dapat mengatur breakpoints dalam kode yang relevan. @amitrajput1992 Apakah mungkin untuk mendapatkan aplikasi pengujian Anda sebagai file sumber yang dapat saya buat/jalankan secara lokal, jadi saya dapat mencoba menukar kode troika untuk debug?

@lojjic Meskipun saya tidak dapat membagikan kode aplikasi asli, izinkan saya menyiapkan repo buku cerita dengan struktur serupa yang saya gunakan di aplikasi produksi saya dan menambahkan render pengujian untuk ini. Akan segera mengirimkan tautannya.

@lojjic
Saya telah menyiapkan repro dasar dengan struktur yang mirip dengan aplikasi produksi saya di sini: https://github.com/amitrajput1992/r3f-experiments
Saya dapat mereplikasi masalah yang sama dengan ini di iPhone 11 saya dan di BrowserStack.
Juga terbitkan buku cerita di sini untuk akses mudah https://amitrajput1992.github.io/r3f-experiments

@amitrajput1992 Terima kasih untuk testcasenya! Saya dapat mereplikasinya di sana setelah memperbaiki kesalahan CORS memuat font dari situs gmetri Anda dengan menyajikannya dari buku cerita.

Namun ... kemudian devtools Safari saya hanya _crashes_ penuh mencoba untuk menyambungkannya! Jadi saya bahkan tidak bisa menambahkan pernyataan console.log dan melihatnya. Bug ini benar-benar tidak ingin diperbaiki, ya?

Merasa frustrasi; Saya akan mencoba untuk kembali ke ini dengan pikiran yang lebih segar besok. Beri tahu saya jika Anda punya ide.

Hai @lojjic , saya tidak memiliki sistem mac saat ini, tetapi saya menguji ini di browserstack dengan penerusan lokal. Sepertinya data sdf yang dicatat di dalam pekerja web vs utas utama berbeda. Bisa jadi karena proses serialisasi-deserialisasi antar komunikasi thread, tapi tidak sepenuhnya yakin. Saya akan terus men-debug ini lebih lanjut.
Anda dapat mencoba crossbrowsertesting jika safari dev-tools tidak bekerja untuk Anda, mereka menawarkan uji coba 100 menit yang mungkin bisa membantu.

tidak dapat mengatur breakpoint dalam kode yang relevan

Saran bodoh untuk melemparkan pesan dari webworker setelah setiap baris kode dan console.log itu, karena kalian dapat mereproduksi bug.

Gambar di iPhone 6/11 saya:

Saran bodoh untuk membuang pesan dari webworker setelah setiap baris kode dan console.log it

Sama sekali bukan saran bodoh! Dan itulah tepatnya yang saya coba lakukan, tetapi devtools Safari langsung mogok untuk saya ketika menunjuk ke instance lokal yang dapat diedit sehingga saya bahkan tidak dapat melihat output console.log. :(

Apakah Anda mencoba membuka url localhost di iPhone yang terhubung? Bagaimana cara kerja penerusan port dalam kasus ini?

Apakah Anda mencoba membuka url localhost di iPhone yang terhubung? Bagaimana cara kerja penerusan port dalam kasus ini?

Saya mengakses server dev dari iPhone melalui alamat IP jaringan lokal. Saya juga sudah mencoba menyalurkannya melalui https://localhost.run. Dalam kedua kasus, Safari devtools crash segera setelah saya membukanya. Halaman itu sendiri dirender dengan baik (meskipun terkadang dengan bug.)

Saya membaca di beberapa blog bahwa ini dapat terjadi dalam 2 skenario:

1. saat baterai ponsel 100%
2. saat debugging melalui jaringan dan bukan koneksi kabel

Ini adalah utas yang berjalan lama pada baris yang sama, tetapi tidak ada resolusi https://developer.apple.com/forums/thread/92290

tetapi devtools Safari langsung mogok untuk saya ketika menunjuk ke instance lokal yang dapat diedit sehingga saya bahkan tidak dapat melihat output console.log. :(

Dimungkinkan untuk mengganti fungsi console.log default dengan sesuatu seperti ini

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

tetapi Anda perlu membuat div itu di halaman html atau dari skrip JS

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

ini akan menampilkan semua pesan konsol di utas utama

Terima kasih @munrocket , itu bisa berhasil, saya akan mencobanya.

Hai semua,

Maaf saya sudah sangat jauh dari thread ini. Idk apakah ini akan membantu dengan debugging, tetapi simulator versi Xcode 13 terbaru (dalam beta) telah dapat menjalankan hal-hal localhost 3D saya dengan baik! Saya mengalami masalah yang Anda bicarakan sebelumnya di mana itu terus macet dengan versi sebelumnya.

@lojjic Adakah keberuntungan dengan ini?

Adakah keberuntungan dengan ini?

Tidak, sayangnya, saya tidak bisa mencurahkan banyak waktu untuk ini baru-baru ini.

apakah ada kemungkinan untuk mematikan pekerja web? hanya untuk cek

Halo semuanya,

Saya telah menemukan masalah yang sama dalam sebuah proyek (sayangnya saya tidak dapat membagikan kodenya) dan akhirnya menemukan jalan ke tiket masalah ini di sini. Karena pembaruan terakhir tentang ini lebih dari sebulan yang lalu, saya memutuskan hari ini untuk mengacaukan kode ketergantungan proyek saya agar mudah-mudahan menunjukkan dengan tepat apa yang sebenarnya terjadi dan baris kode mana yang berkontribusi terhadap bencana UX ini.

Sebelum saya melangkah lebih jauh, saya ingin menyoroti bahwa informasi dan tweak di bawah ini sama sekali tidak disarankan, dan dibagikan di sini murni untuk membantu mencari solusi yang sebenarnya. Informasi di bawah ini BUKAN solusi. Anda telah diperingatkan.

Pertama. Ya, seperti yang disebutkan sebelumnya dalam diskusi, ini tampaknya memang kesalahan WebWorker di iOS Safari secara spesifik. Firefox (win10), Chrome (win10), Opera (win10), Safari (macOS big sur), dan lainnya tidak menampilkan masalah ini dan font dimuat dengan benar 100% setiap saat. Safari (iOS), bagaimanapun, mengalami semacam kondisi balapan antara beberapa WebWorkers (saya belum mengidentifikasi apakah ini sepenuhnya benar atau panggilan async mana yang mengganggu satu sama lain).

Kedua. Kondisi balapan yang diduga ini (atau apa pun itu) menyebabkan buffer yang berisi data font sedang dimuat untuk menghasilkan beberapa nilai NaN saat diakses melalui fungsi readShort dalam ketergantungan Typr Troika. Jadi, apakah masalahnya sebenarnya di Typr? Mungkin. Saya tidak yakin. Namun, beberapa nilai NaN ini mengalir ke tumpukan panggilan yang secara harfiah merusak segalanya dan akhirnya menyebabkan mesin terbang ditampilkan sepenuhnya salah.

Ketiga. Setelah menunjukkan dengan tepat lokasi yang saya butuhkan (fungsi readShort ini di Typr/bin.s ), saya mengubahnya dalam beberapa cara untuk memahami apa yang sedang terjadi.

        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];
    },

Ketika saya hanya menggunakan console.log(Typr._bin.t.int16[0]), aplikasi akan mencetak beberapa NaN yang seharusnya tidak pernah (hati-hati mencoba ini karena seluruh aplikasi dapat menggantung barang-barang pencetakan - fungsi ini disebut ribuan kali tergantung pada kasus penggunaan). Namun, seperti yang diharapkan, menjeda aplikasi di mana saja di dalam fungsi ini (dengan kata kunci debugger atau breakpoint atau bahkan mengakses konsol) menyebabkan nilai mengoreksi dirinya sendiri dan tidak menghasilkan NaN (yang membuat saya percaya pada kondisi balapan). Itu berarti Anda tidak dapat memeriksa masalah dengan debugger dengan cara konvensional.

Keempat dan terakhir. Ini adalah bagian yang saya sarankan jika bukan untuk tujuan menemukan solusi aktual untuk masalah ini. Perhatikan bahwa saya menulis di atas bahwa jika bahkan konsol digunakan di dalam fungsi readShort, NaN menghilang. Jadi pola pikir peretas saya yang cerdik memikirkan ide cemerlang untuk memasukkan cuplikan ini sebelum pernyataan kembali readShort:

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

Dan itu berhasil! Semua teks sekarang ditampilkan dengan baik di iOS Safari serta semua browser lain yang saya uji sebelumnya. Masalah terpecahkan~... agak, dengan cara yang paling buruk. Ternyata jendela singkat yang dibuat aplikasi untuk mengakses konsol menyelesaikan dugaan kondisi balapan. Dan perhatikan bahwa itu hanya terjadi ketika terhubung ke konsol.

Kesimpulannya. Di sinilah aku berada. Solusi yang mengerikan berhasil, tetapi saya masih mencari solusi aktual untuk ini seperti yang seharusnya dilakukan semua orang di sini. Ternyata masalahnya mungkin atau mungkin tidak di Troika, karena mungkin sudah ada di Typr selama ini, atau bahkan implementasi WebWorker iOS (siapa tahu). Bagaimanapun, saya harap semua informasi ini membantu dalam penyelidikan dan kita semua melihat ini sampai akhir.

Tumpukan panggilan referensi:
Ketik/bin.js - readShort
Typr/glyf.js - _parseGlyf
Typr/Typr.U.js - _drawGlyf
Typr/Typr.U.js - glyphToPath
Troika/FontParser_Typr.js - (Anonim) untuk SetiapGlyph
Troika/FontParser_Typr.js - wrapFontObj
Troika/FontParser_Typr.js - parse
...Barang pekerja

Dan @lojjic , mengenai pemecahan masalah dengan debugging Safari iOS melalui USB menggunakan MacOS Safari:
Saya menyarankan untuk mencoba memutuskan dan menyambung kembali ke jaringan lokal atau telepon Anda jika MacOS Safari DevTools bersikeras memuat tanpa batas waktu atau menampilkan pesan yang mengatakan halaman macet atau tidak memuat skrip atau apa yang tidak. Entah itu, atau coba tutup dan buka kembali DevTools beberapa kali. Dan kemudian menyegarkan halaman web di telepon dengan jelas. Saya mengatakan ini karena ini terjadi pada saya hari ini beberapa kali (sakit) dan saya menyelesaikannya dengan cara itu (menghubungkan antara MacOS Big Sur dan iOS 15.0.1).

OMG @malulleybovo Saya kembali dari liburan dan melihat temuan Anda dan wow itu kejutan yang menyenangkan! Terima kasih banyak untuk menggali ini.

Mengetahui bahwa readShort memproduksi NaNs adalah langkah _besar_ maju dalam mungkin akhirnya memahami masalah ini, yang seperti yang Anda tahu saya telah benar-benar terjebak selama beberapa waktu. Itu tidak membantu bahwa saya mengubah pekerjaan dan kehilangan akses ke perangkat iOS yang saya gunakan.

Pertanyaan saya selanjutnya adalah dapatkah kita menentukan _why_ pembacaan Typr._bin.t.int16[0] menghasilkan NaN? Tampaknya itu harus mendapatkan nilai yang salah di salah satu buffer (baik font buff atau utilitas Typr._bin.t.buff ), tetapi akan membantu untuk mengetahui dengan tepat apa nilai buff/uint8/int16 berada pada saat itu versus apa yang seharusnya.

Fakta bahwa Anda dapat memasukkan console.log() di sana untuk menghindari bug itu aneh. Saya tidak yakin apakah itu menunjukkan kondisi balapan, atau mungkin mengakses konsol mengeluarkannya dari mode JIT. Saya berharap untuk yang pertama, karena kedengarannya lebih mudah untuk dideteksi dan diselesaikan.

@lojjic selamat atas perubahan pekerjaan!

Saya baru saja menggali lebih dalam masalah ini sekarang dan saya mendapat berita yang lebih menarik dan aneh tentang ini. Kembali ke cuplikan kode readShort yang saya bagikan sebelumnya, saya mencoba mengintip nilai array (dengan buffer array bersama) dan menemukan hal paling aneh yang pernah saya lihat dalam karir rekayasa perangkat lunak saya sejauh ini.

        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];
    },

Saat mengintip kemunculan pertama NaN di readShort dalam aplikasi saya, saya menemukan bahwa buff[p]=255 dan buff[p+1]=6 (keduanya valid nilai uint8). Dengan mengingat hal itu, saya mengintip nilai-nilai Typr._bin.t.uint8 dan ternyata memiliki [6, 255, 0, ...] seperti yang diharapkan. Kemudian saya mengintip Typr._bin.t.int16 dan menemukan [NaN, 0, ...] yang salah daripada [-250, 0, ...]. Terakhir, saya mengintip Typr._bin.t.int8 dan... itu juga salah... itu [6, NaN, 0, ...] bukannya [6, -1, 0, ...] .

Pustaka glyf Typr menggunakan satu ArrayBuffer bersama pada beberapa Array dengan tipe berbeda (Uint8Array, Int8Array, Int16Array, dll.). Kejadian ini menunjukkan kepada saya bahwa di Safari iOS (hanya), setelah mengubah salah satu larik ini, nilai pada larik lainnya mungkin tidak segera diperbarui. Tidak tahu mengapa, tetapi saya menemukan laporan bug yang diselesaikan yang melibatkan ArrayBuffer di iOS Safari dalam sejarah baru-baru ini yang membuat ini lebih dapat dipercaya ... terbukti cacat sekali, mungkin terbukti cacat dua kali (ref: (https://bugs.webkit .org/show_bug.cgi?id=194268)[https://bugs.webkit.org/show_bug.cgi?id=194268)).

Setelah menemukan ini, saya memutuskan untuk mencoba implementasi alternatif dari konversi (uint8,uint8) to int16 . Kali ini menggunakan operasi bitwise. Kode yang saya gunakan adalah sebagai berikut:

        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;
    },

Dan di sana Anda memilikinya. Semua teks dengan font sekarang selalu ditampilkan dengan benar (bahkan tanpa terhubung ke devtools - lihat komentar saya sebelumnya tentang hal console.log untuk memahami penafian ini) Solusi alternatif ini memperbaiki masalah di iOS Safari (diuji pada iOS 15.0.2) , dan terus bekerja di browser sebelumnya yang saya uji sebelumnya seperti sebelumnya, seperti Chrome v95.0.4638.54 (win10), Firefox v93.0 (win10), Opera v80.0.4170.63 (win10), dan MacOS Safari (MacOS Big Sur v11.3.1).

*Jika ada yang bisa mengoptimalkan cuplikan kode saya di atas, silakan~

Pada akhirnya, menurut saya masalah ini bukan disebabkan oleh troika. Troika tampaknya sebenarnya menderita konsekuensi dari masalah yang lebih dalam. Jadi saya pribadi akan memindahkan masalah ini ke Typr. Tapi apa yang saya tahu ... mengujinya sendiri dan mari kita berdebat apakah ini benar-benar akar masalahnya. ;)

Saya pikir @malulleybovo pantas mendapatkan penghargaan atau semacamnya! 🥳.

Ini luar biasa, mempersempitnya dan menghasilkan implementasi alternatif yang menghindari masalah! Terima kasih banyak!

Saya senang mengintegrasikan solusi readShort Anda, sebagai penggantian lokal di troika dan/atau hulu di Typr. Kami mungkin ingin implementasi alternatif untuk metode readFoo lainnya juga?

Sepertinya ada yang salah/berbahaya dengan pola typed-arrays-sharing-a-buffer secara umum. Ini pola yang cukup aneh sekarang setelah saya memikirkannya. Sepertinya DataView dimaksudkan persis untuk tujuan membaca berbagai format angka dari biner, tanpa konversi nilai yang aneh antara angka uints dan JS atau inkonsistensi endianness ... Saya ingin tahu apakah itu juga akan menyelesaikan masalah? Sesuatu seperti ini mungkin? https://Gist.github.com/lojjic/94d7b5f5f374598fe0e9761be45ebb2b

Terima kasih atas pujiannya @lojjic~ Saya senang bisa membantu.

Solusi yang Anda usulkan sepertinya menjanjikan, jadi saya baru saja mengujinya dan coba tebak, ini juga berfungsi (di semua browser yang saya daftarkan sebelumnya)!
Menggunakan DataView sepertinya cara yang ringkas dan tepat untuk mengimplementasikan ini di JS jika Anda bertanya kepada saya. bagus.

Aplikasi saya bergantung pada skrip glyf Typr, yang menggunakan readInt8, readShort, readUshort, dan readBytes Typr. Meskipun saya telah menyertakan solusi lengkap Anda untuk tujuan pengujian, saya hanya mengujinya pada fungsi-fungsi ini. Dan semuanya bekerja dengan kelihatannya.

Untuk melihat lebih mendalam tentang efektivitas solusi ini, saya akan menguji skenario lain. Tetapi saya kekurangan contoh nyata untuk menguji ini (selain hanya pengujian unit).

Saya percaya readFixed, readF2dot14, readUshorts, readUint64, readASCII, readUnicode, readUTF8, readBytes, dan readASCIIArray dari bin.js tidak perlu diubah karena mereka tidak secara langsung menggunakan array yang diketik. Jadi hanya fungsi di Intisari Anda yang perlu diubah dalam Typr. Plus, bersama dengan perubahan ini, ArrayBuffer dan array yang diketik Typr akan menjadi usang.

Jika lebih banyak pengembang dapat menguji dan memberikan persetujuan untuk ini, kami akan lebih percaya diri dalam solusinya. Ini karena saya memiliki sejumlah kasus uji dan perangkat uji yang saya miliki dan ada kemungkinan kecil hasil tes bias.

Solusi yang Anda usulkan sepertinya menjanjikan, jadi saya baru saja mengujinya dan coba tebak, ini juga berfungsi (di semua browser yang saya daftarkan sebelumnya)!
Menggunakan DataView sepertinya cara yang ringkas dan tepat untuk mengimplementasikan ini di JS jika Anda bertanya kepada saya. bagus.

Luar biasa!!! Aku hampir tidak percaya. 🎉 🥳.

Saya akan memberikan ini beberapa pengujian lagi untuk melihat apakah saya dapat memvalidasi fungsi lain, dan melakukan perbandingan kinerja dasar. Kecuali sesuatu yang buruk muncul, saya akan mengintegrasikan ini secepatnya. Saya cukup yakin memasukkan ini ke dalam rilis troika-tiga teks sehingga orang dapat mencobanya; komunitas akan memberi tahu kami jika ada masalah yang muncul dengannya. Setelah sedikit keluar di alam liar, saya akan mengirimkannya ke hulu ke Typr.

Kinerja tampaknya sebanding, bahkan sedikit lebih cepat dalam beberapa kasus. Kemenangan ekstra! 😄.

Saya telah memverifikasi bahwa fungsi lain juga berfungsi. Saya harus sedikit memodifikasi _view helper untuk menangani kasus dalam font CFF di mana Typr melewatkan buff sebagai array JS biasa daripada Uint8Array.

Saya telah menerbitkan versi troika-three-test 0.43.1-alpha.0 dengan perbaikan DataView di dalamnya (saat ini menggunakan garpu pribadi Typr - komit yang relevan )

Siapapun yang dapat (@amitrajput1992? @strangerintheq? @atlmtw?), saya akan sangat menghargai pengujian dengan versi ini untuk memverifikasi bahwa itu memperbaiki masalah dalam aplikasi spesifik Anda. Saya akan mencoba melakukan hal yang sama baik dengan Browserstack atau mencari iPhone untuk dipinjam. Terima kasih sebelumnya!

Hai @lojjic senang mendengar bahwa ada perbaikan untuk itu. Biarkan saya menguji ini dengan cepat dan menghubungi Anda kembali.

@amitrajput1992 Hai, apakah Anda sudah memiliki kesempatan untuk menguji alfa? Saya ingin ini dirilis dan akan menyukai validasi ekstra. :)

@lojjic Hei, saya baru saja punya waktu untuk menguji ini. Sepertinya berhasil sekarang!!

Lihat perubahannya di sini: https://amitrajput1992.github.io/r3f-experiments/?path=/story/testers --text-tester

Saya telah merilis versi 0.44.0 dengan perbaikan untuk bug jahat ini. Saya sangat senang akhirnya memperbaiki ini! Terima kasih semuanya atas bantuannya, dan terutama @maulleybovo karena telah menggali lebih dalam di mana saya tidak dapat menemukan akar masalahnya. Saya sangat berterima kasih! 🥳.