Troika: [troika-three-text] Problèmes de chargement de Safari IOS

Merci d'avoir signalé cela ! Vous n'êtes pas le premier à décrire des problèmes comme celui-ci dans iOS Safari, mais je n'ai pas pu le reproduire auparavant. Je vais essayer avec votre site et j'espère pouvoir le reproduire.

L'utilisez-vous via drei par hasard ? Ou directement ?

Hey @lojjic J'utilise ce package directement avec three.js. Et la raison pour laquelle j'ai trois utilitaires est que j'utilise également votre fonction createDerivedMaterial dans certains cas.

Merci d'avoir vérifié cela !

J'ai pu reproduire le(s) problème(s) de chargement de votre site Web sur un iPhone 8. Je n'ai pas encore eu le temps de commencer le débogage mais je voulais juste reconnaître que le bug est reproductible.

@atlmtw @lojjic J'ai eu le même problème sur safari sur un projet qui utilisait plusieurs polices. Le seul correctif que j'ai trouvé était d'utiliser une police unique sur l'ensemble du site Web pour ce navigateur.

+1
plusieurs polices par scène = certaines polices n'apparaissent jamais sur iphone X, iphone SE

J'essaie de creuser ce problème, et j'ai du mal à le reproduire maintenant. Même iPhone 8 qu'avant. Je ne peux plus le reproduire sur designsdalena.com, mais il est possible que le site ait changé pour ne plus utiliser troika-three-text ou l'a contourné d'une autre manière.

J'essaie donc de créer un cas de test minimal à l'aide de plusieurs polices et je n'arrive pas à le faire échouer :

https://uqgxq.csb.app/

Est-ce que quelqu'un d'autre est capable de reproduire cela quelque part que je pourrais utiliser pour tester/déboguer ?

Salut @lojjic

Pour confirmer, je suis passé à autre chose. Bien que j'apprécie davantage l'expérience d'utiliser la troïka.

@atlmtw Merci pour la confirmation. Je suppose que vous n'avez pas une ancienne version de votre site en contrôle de source que vous seriez en mesure de m'envoyer ? J'ai du mal à reproduire cela et le vôtre semblait être une reproduction fiable.

Salut @lojjic
De la chance avec ça? J'ai également vu cela lorsque> 1 polices sont utilisées, sur un iPhone (fonctionne sur iPad et macOS). Bizarrement, ce n'est pas reproductible tout le temps, cela ne se produit que 1 à 2 fois sur 10 et uniquement au 1er chargement. Lié aux téléchargements de fichiers de polices peut-être ?

Au fait, j'adore le travail :100:

@ amitrajput1992 Non, je n'ai toujours pas été en mesure de construire un cas de test reproductible. En avez-vous un que je pourrais utiliser ?

@lojjic
Essayez ceci ?
Si vous ouvrez sur un bureau, vous devriez voir 6 textes différents imprimés avec des couleurs différentes.
J'ai testé ce lien sur quelques appareils avec moi et quelques-uns sur BrowserStack, tous montrent le problème de rendu. Actualiser le lien plusieurs fois le fait fonctionner, ce qui est très étrange.

C'est ce que je vois sur BrowserStack. C'est sur Iphone 8 + Safari v13

Celui-ci sur mon iPhone 11 + Safari 14

Cela pourrait-il avoir quelque chose à voir avec le fait que les fichiers de polices sont téléchargés dans le web-worker ? Nous savons que le safari peut être pénible pour les travailleurs du Web

@ amitrajput1992 Merci, je peux en effet reproduire le problème sur cette page. Je verrai si je peux déboguer à partir de là et/ou le répliquer dans un cas de test local minimisé.

Nous savons que le safari peut être pénible pour les travailleurs du Web

J'ai entendu d'autres dire cela aussi, et l'utilisation d'un travailleur est certainement un coupable plausible, mais je n'ai pas pu trouver de détails sur les bogues connus avec les travailleurs dans Safari. Avez-vous des détails là-bas que vous pouvez partager?

@lojjic
Ça sonne bien. Faites-moi savoir si je peux aider de quelque manière que ce soit. Pendant ce temps, je vais continuer à déboguer et essayer de réduire le problème de mon côté aussi.

J'ai entendu d'autres dire cela aussi, et l'utilisation d'un travailleur est certainement un coupable plausible, mais je n'ai pas pu trouver de détails sur les bogues connus avec les travailleurs dans Safari. Avez-vous des détails là-bas que vous pouvez partager?

Je ne connais pas les problèmes exacts ici, en partie parce que je ne les trouve nulle part (ou que les gens ne les enregistrent pas), mais c'est quelque chose que j'ai remarqué en bricolant. react360 anciennement react-vr (abandonné maintenant) exécutait tout le code de réaction à l'intérieur d'un travailleur Web et les mises à jour du fil principal étaient trop lentes. Il faudrait facilement une action de clic n'importe où autour de 300 ms à 500 ms pour se propager à mon écouteur de clic dans le fil de travail et manquerait souvent quelques clics aussi.
Je maintiens un repo qui est un moteur de rendu gif pour trois, essayé initialement avec une toile hors écran mais les résultats ont été horribles et ont abouti à un mélange de textures sur des images consécutives. Déplacer le tout vers le thread principal l'a considérablement amélioré.

Je pense que cela pourrait être lié à l'algorithme de clonage structuré utilisé lors de la transmission d'informations du travailleur au thread principal. Bien que je n'ai pas été en mesure de trouver une preuve solide autour de cette limitation sur iOS

Je pense que je devrais d'abord me concentrer sur ces artefacts, qui n'apparaissent pas toujours mais parfois :

Dans ces cas, la mise en page et la génération de SDF se terminent évidemment et reviennent au thread principal, mais certains des SDF semblent avoir des remplissages intérieurs/extérieurs inversés par endroits. Je peux voir comment cela pourrait se produire si les données de chemin pour ces caractères sont incomplètes, comme n'avoir que la moitié de ses segments de chemin.

Si quelque chose se passe pendant le chargement de la police où le tableau tampon de la police est tronqué ou corrompu, je pense que cela pourrait éventuellement entraîner ce symptôme observé. De même, cela pourrait également entraîner des résultats totalement vides s'ils sont tronqués à certains endroits.

J'étudierai cela comme une possibilité (peut-être que XHR donne une réponse partielle au tampon de matrice?), Mais la première étape consiste à intégrer cela dans un cas de test reproductible que je peux modifier et exécuter localement.

Ça a du sens. la corruption de arraybuffer pourrait être un coupable ici.
J'ai vu une autre discussion sur l'exécution de tout ce processus sur le thread principal. C'est sur la feuille de route ?

De plus, si cela peut aider, j'utilise troika en utilisant drei avec les versions ci-dessous :
@react-three/fibre : 6.2.3
@réagir-trois/drei : 6.0.1
troïka : 0.42.0
trois : 0,129,0

L'exécution sur le thread principal est possible, mais entraînerait une expérience assez merdique bloquant le thread principal pendant potentiellement plusieurs secondes. Cela ne devrait être qu'un dernier recours.

Votre page de test a-t-elle changé ? Il semble qu'il n'utilise plus qu'une seule police pour tous les différents objets texte maintenant, du moins sur iOS... ? Cependant, je vois toujours des fichiers SDF brouillés avec cette seule police, ce qui implique que cela peut être exacerbé par plusieurs polices, mais ne se limite pas à cela.

J'ai ajouté une solution de repli pour les appareils iOS afin d'utiliser une seule police pour l'ensemble de l'application. Ceci est mon environnement de production, donc je ne peux pas avoir de choses cassées là-bas.
Je vais créer un autre exemple dans mon environnement de mise en scène et envoyer un lien ici dès que possible.

Il est gênant de découvrir que cela se produit toujours avec une seule police aussi :facepalm:

Hmm, il semble en fait que je ne puisse obtenir le bogue qu'avec votre nouvelle police unique lorsqu'elle est connectée aux outils de développement Safari, et c'est alors assez régulièrement bogué. Je ne sais pas si cela nous donne un indice ou non.

Eh bien, un peu plus de progrès ... J'ai vérifié que je suis capable de forcer les mêmes artefacts de glyphe partiels vus ci-dessus en tronquant les commandes de chemin pour les glyphes individuels. Je n'ai pas encore été en mesure de déterminer si cela est dû au fait que les données de police d'origine sont incomplètes (je pense que cela ne causerait qu'un seul glyphe partiel, pas beaucoup, donc cela semble peu probable), ou si quelque chose provoque les boucles for quittez tôt (cela semble impossible, mais il y a peut-être un bogue JIT étrange).

Quoi qu'il en soit, je suis coincé avec les outils de développement de connexion USB de Safari qui ne peuvent pas définir de points d'arrêt dans le code correspondant. @amitrajput1992 Serait-il possible d'obtenir votre application de test sous forme de fichiers source que je peux créer/exécuter localement, afin que je puisse essayer d'échanger le code de la troïka pour déboguer ?

@lojjic Bien que je ne puisse pas partager le code d'application d'origine, permettez-moi de configurer un dépôt de livre de contes avec une structure similaire à celle que j'utilise dans mon application de production et d'ajouter un rendu de test pour cela. Enverra le lien sous peu.

@lojjic
J'ai mis en place une reproduction de base avec une structure similaire à celle de mon application de production ici : https://github.com/amitrajput1992/r3f-experiments
Je peux reproduire le même problème avec ceci sur mon iPhone 11 et sur BrowserStack.
A également publié le livre d'histoires ici pour un accès facile https://amitrajput1992.github.io/r3f-experiments

@amitrajput1992 Merci pour le cas de test ! Je peux le reproduire là-bas après avoir corrigé les erreurs CORS en chargeant les polices de votre site gmetri en les servant à partir du livre de contes.

Cependant ... alors mes outils de développement Safari se bloquent complètement en essayant de s'y connecter ! 🤦🤦🤦🤦🤦🤦 Je ne peux donc même pas ajouter d'instructions console.log et les voir. Ce bogue ne veut vraiment pas être corrigé, hein ?

Se sentir frustré; J'essaierai d'y revenir avec un esprit plus frais demain. Faites-moi savoir si vous avez des idées.

Hey @lojjic , ​​je n'ai pas de système mac avec moi pour le moment, mais j'ai testé cela sur browserstack avec redirection locale. Il semble que les données sdf enregistrées dans le thread de travail Web et le thread principal soient différentes. Cela pourrait être dû au processus de sérialisation-désérialisation entre la communication de thread, mais pas entièrement sûr. Je vais continuer à déboguer cela plus loin.
Vous pouvez essayer les tests croisés si les outils de développement Safari ne fonctionnent pas pour vous, ils offrent un essai de 100 minutes qui pourrait être utile.

ne pas pouvoir définir de points d'arrêt dans le code correspondant

Suggestion stupide de lancer un message de webworker après chaque ligne de code et console.log, puisque vous êtes capables de reproduire le bogue.

Image sur mon iPhone 6/11 :

Suggestion stupide de lancer un message du webworker après chaque ligne de code et console.log it

Pas une suggestion stupide du tout! Et c'est exactement ce que j'essayais de faire, mais les outils de développement de Safari se bloquent immédiatement pour moi lorsque je pointe vers une instance modifiable locale, donc je ne peux même pas voir la sortie console.log. :(

Essayez-vous d'ouvrir une URL localhost dans l'iPhone connecté ? Comment fonctionne la redirection de port dans ce cas ?

Essayez-vous d'ouvrir une URL localhost dans l'iPhone connecté ? Comment fonctionne la redirection de port dans ce cas ?

J'accède au serveur de développement depuis l'iPhone via l'adresse IP du réseau local. J'ai également essayé de le diriger via https://localhost.run. Dans les deux cas, Safari devtools se bloque dès que je l'ouvre. La page elle-même s'affiche très bien (mais avec le bogue parfois.)

J'ai lu sur quelques blogs que cela peut se produire dans 2 scénarios :

1. lorsque la batterie du téléphone est à 100 %
2. lors du débogage via le réseau et non la connexion par câble

Il s'agit d'un fil de discussion de longue date sur des lignes similaires, mais pas de résolution https://developer.apple.com/forums/thread/92290

mais les outils de développement de Safari se bloquent immédiatement pour moi lorsque je pointe vers une instance modifiable locale, donc je ne peux même pas voir la sortie console.log. :(

Il est possible de remplacer la fonction console.log par défaut par quelque chose comme ceci

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

mais vous devez créer cette div sur la page html ou à partir du script JS

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

cela devrait afficher tous les messages de la console sur le fil principal

Merci @munrocket , ça pourrait marcher, je vais essayer.

Salut à tous,

Désolé, j'ai été si loin de ce fil. Idk si cela aiderait au débogage, mais le simulateur des versions récentes de Xcode 13 (en version bêta) a été en mesure d'exécuter correctement mes trucs 3D localhost! J'ai rencontré les problèmes dont vous avez tous parlé auparavant, où il n'arrêtait pas de planter avec les versions antérieures.

@lojjic Avez -vous de la chance avec ça?

De la chance avec ça?

Non, malheureusement, je n'ai pas pu y consacrer beaucoup de temps récemment.

y a-t-il une possibilité de désactiver les web workers ? juste pour vérifier

Bonjour à tous,

Je suis tombé sur ce même problème dans un projet (pour lequel je ne peux malheureusement pas partager de code) et j'ai finalement trouvé mon chemin vers ce ticket de problème ici. Étant donné que la dernière mise à jour à ce sujet remonte à plus d'un mois, j'ai décidé aujourd'hui de jouer avec le code de dépendance de mon projet pour, espérons-le, identifier exactement ce qui se passe et quelles lignes de code contribuent à ce désastre UX.

Avant d'aller plus loin, je tiens à souligner que les informations et les ajustements ci-dessous ne sont en aucun cas conseillés et sont partagés ici uniquement pour aider à la recherche d'une solution réelle. Les informations ci-dessous ne sont PAS une solution. Tu as été prévenu.

Première. Oui, comme mentionné précédemment dans la discussion, cela semble en effet être la faute du WebWorker dans iOS Safari en particulier. Firefox (win10), Chrome (win10), Opera (win10), Safari (macOS big sur) et d'autres ne présentent pas ce problème et les polices sont correctement chargées 100 % du temps. Safari (iOS), cependant, se heurte à une sorte de condition de concurrence entre plusieurs WebWorkers (je n'ai pas identifié si cela est complètement vrai ni quels appels asynchrones interfèrent les uns avec les autres).

Seconde. Cette prétendue condition de concurrence (ou quoi que ce soit d'autre) fait que le tampon contenant les données de police chargées produit quelques valeurs NaN lorsqu'il est accédé via la fonction readShort dans la dépendance Typr de Troika. Alors, le problème est-il réellement dans Typr ? Peut-être. Je ne suis pas certain. Cependant, ces quelques valeurs NaN remontent en cascade la pile d'appels, ruinant littéralement tout et provoquant finalement l'affichage complètement faux du glyphe.

La troisième. Après avoir identifié l'emplacement exact dont j'avais besoin (cette fonction readShort dans Typr/bin.s ), je l'ai modifiée de plusieurs manières pour comprendre ce qui se passait.

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

Lorsque j'utilisais simplement un console.log(Typr._bin.t.int16[0]), l'application imprimait quelques NaN qui ne devraient jamais l'être (faites attention en essayant car toute l'application peut bloquer des éléments d'impression - cette fonction s'appelle des milliers de fois selon le cas d'utilisation). Cependant, comme prévu, la mise en pause de l'application n'importe où dans cette fonction (avec le mot-clé du débogueur ou le point d'arrêt ou même l'accès à la console) provoque la correction de la valeur et ne produit pas NaN (ce qui m'a amené à croire à une condition de concurrence). Cela signifie que vous ne pouvez pas inspecter le problème avec un débogueur de manière conventionnelle.

Quatrième et enfin. C'est la partie que je déconseille si ce n'est dans le but de trouver la solution réelle à ce problème. Notez que j'ai écrit ci-dessus que même si la console est utilisée dans la fonction readShort, les NaN disparaissent. Donc, mon ingénieux état d'esprit de hacker a pensé à l'idée brillante d'inclure cet extrait avant l'instruction de retour de readShort :

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

Et ça a marché ! Tout le texte s'affiche désormais correctement dans iOS Safari ainsi que dans tous les autres navigateurs que j'ai testés auparavant. Problème résolu ~... un peu, de la pire façon possible. Il s'avère que la brève fenêtre créée par l'application pour accéder à la console résout la prétendue condition de concurrence. Et notez qu'il ne le fait que lorsqu'il est connecté à la console.

En conclusion. C'est là que j'en suis. La terrible solution de contournement fonctionne, mais je cherche toujours une solution réelle à cela, comme tout le monde ici le devrait aussi. Il s'est avéré que le problème pouvait ou non être dans Troika, car il se trouvait peut-être dans Typr depuis le début, ou même dans l'implémentation de WebWorker par iOS (qui sait). En tout cas, j'espère que toutes ces informations aideront à l'enquête et que nous irons tous jusqu'au bout.

Pile d'appels de référence :
Typr/bin.js - readShort
Typr/glyf.js - _parseGlyf
Typr/Typr.U.js - _drawGlyf
Typr/Typr.U.js - glyphToPath
Troïka/FontParser_Typr.js - (Anonyme) pourEachGlyph
Troïka/FontParser_Typr.js - wrapFontObj
Troïka/FontParser_Typr.js - analyse
...Des trucs de travailleurs

Et @lojjic , concernant le dépannage du débogage iOS Safari via USB à l'aide d'un MacOS Safari :
Je vous conseille d'essayer de vous déconnecter et de vous reconnecter au réseau local ou à votre téléphone si MacOS Safari DevTools insiste pour se charger indéfiniment ou affiche un message indiquant que la page s'est écrasée ou ne charge pas les scripts ou autre. Soit cela, soit essayez de fermer et de rouvrir DevTools plusieurs fois. Et puis actualiser la page Web sur le téléphone évidemment. Je dis cela parce que cela m'est arrivé plusieurs fois aujourd'hui (douleur) et que je l'ai résolu de cette façon (connexion entre MacOS Big Sur et iOS 15.0.1).

OMG @malulleybovo Je suis rentré de vacances et j'ai vu vos découvertes et wow c'était une merveilleuse surprise ! 😃 Merci beaucoup d'avoir creusé cela.

Le simple fait de savoir que readShort produit des NaN est un _énorme_ pas en avant pour peut-être enfin comprendre ce problème, sur lequel, comme vous le savez, j'étais totalement bloqué depuis un certain temps. Cela n'a pas aidé que j'ai changé d'emploi et perdu l'accès à l'appareil iOS que j'utilisais.

Ma prochaine question serait de savoir si nous pouvons déterminer _pourquoi_ la lecture Typr._bin.t.int16[0] produit un NaN ? Il semble qu'il doit obtenir une valeur incorrecte dans l'un des tampons (soit buff la police ou l'utilitaire Typr._bin.t.buff ), mais il serait utile de savoir exactement quelles sont les valeurs buff/uint8/int16 sont à ce moment-là par rapport à ce qu'ils devraient être.

Le fait que vous puissiez y insérer le console.log() pour éviter le bogue est curieux. Je ne sais pas si cela indique une condition de concurrence, ou peut-être que l'accès à la console la sort du mode JIT. J'espère pour le premier, car cela semble plus facile à détecter et à contourner.

@lojjic félicitations pour le changement de travail !

Je viens de creuser un peu plus ce problème en ce moment et j'ai reçu des nouvelles plus intéressantes et étranges à ce sujet. Pour en revenir à l'extrait de code readShort que j'ai partagé auparavant, j'ai essayé de jeter un coup d'œil sur les valeurs du tableau (avec un tampon de tableau partagé) et j'ai trouvé la chose la plus bizarre que j'ai vue dans ma carrière d'ingénieur logiciel jusqu'à présent.

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

En regardant la première occurrence de NaN dans readShort dans mon application, j'ai découvert que buff[p]=255 et buff[p+1]=6 (les deux valeurs uint8 valides). Dans cet esprit, j'ai jeté un coup d'œil aux valeurs de Typr._bin.t.uint8 et j'ai trouvé qu'il avait [6, 255, 0, ...] comme prévu. Ensuite, j'ai jeté un coup d'œil à Typr._bin.t.int16 et j'ai trouvé l'erreur [NaN, 0, ...] au lieu de [-250, 0, ...]. Enfin, j'ai jeté un coup d'œil à Typr._bin.t.int8 et... c'était aussi faux... c'était [6, NaN, 0, ...] au lieu de [6, -1, 0, ...] .

La bibliothèque Typr glyf utilise un ArrayBuffer partagé sur plusieurs tableaux de types différents (Uint8Array, Int8Array, Int16Array, etc.). Cet événement m'a montré que dans iOS Safari (uniquement), après avoir modifié l'un de ces tableaux, les valeurs des autres pourraient ne pas être mises à jour immédiatement. Je ne sais pas pourquoi, mais j'ai trouvé un rapport de bogue résolu impliquant ArrayBuffer dans iOS Safari dans l'histoire récente, ce qui le rend plus crédible... s'est avéré défectueux une fois, pourrait bien être défectueux deux fois (réf : (https://bugs.webkit .org/show_bug.cgi?id=194268) [https://bugs.webkit.org/show_bug.cgi?id=194268]).

Ayant découvert cela, j'ai décidé d'essayer une autre implémentation de la conversion (uint8,uint8) to int16 . Cette fois en utilisant des opérations au niveau du bit. Le code que j'ai utilisé est le suivant :

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

Et voila. Tout le texte avec la police s'affiche désormais toujours correctement (même sans être connecté à devtools - reportez-vous à mon commentaire précédent sur la chose console.log pour comprendre cet avertissement) Cette solution alternative a résolu le problème dans iOS Safari (testé sur iOS 15.0.2) , et continue de fonctionner dans les navigateurs précédents que j'ai testés auparavant, comme avant, tels que Chrome v95.0.4638.54 (win10), Firefox v93.0 (win10), Opera v80.0.4170.63 (win10) et MacOS Safari (MacOS Big Sur v11.3.1).

* Si quelqu'un peut optimiser mon extrait de code ci-dessus, n'hésitez pas ~

En fin de compte, il me semble que ce problème n'est pas causé par la troïka. La Troïka semble en fait subir les conséquences d'un problème plus profond. Je déplacerais donc personnellement ce problème vers Typr à la place. Mais qu'est-ce que je sais ... testez-le par vous-mêmes et discutons si c'est vraiment la racine du problème. ;)

Je pense que @malulleybovo mérite un prix ou quelque chose comme ça ! 🥳

C'est incroyable, le réduire et proposer une implémentation alternative qui évite le problème ! Merci beaucoup !

Je suis heureux d'intégrer votre solution readShort , en tant que remplacement local dans la troïka et/ou en amont dans Typr. Nous pourrions également vouloir des implémentations alternatives pour les autres méthodes readFoo ?

Il semble qu'il y ait quelque chose qui ne va pas/dangereux avec le modèle typed-arrays-sharing-a-buffer en général. C'est un modèle assez curieux maintenant que j'y pense. Il semble que DataView soit destiné exactement à lire divers formats de nombres à partir de binaires, sans aucune conversion de valeur étrange entre les nombres uints et JS ou les incohérences d'endianness... Je me demande si cela résoudrait également le problème ? Quelque chose comme ça peut-être ? https://gist.github.com/lojjic/94d7b5f5f374598fe0e9761be45ebb2b

Merci pour le compliment @lojjic~ Je suis content d'avoir été utile.

Votre solution proposée semblait prometteuse, je viens donc de la tester et devinez quoi, elle fonctionne également (sur tous les navigateurs que j'ai énumérés précédemment) !
L'utilisation de DataView semble être un moyen concis et approprié d'implémenter cela dans JS si vous me le demandez. Joli.

Mon application dépend du script glyf de Typr, qui utilise readInt8, readShort, readUshort et readBytes de Typr. Bien que j'aie inclus votre solution complète à des fins de test, je ne l'ai testée que sur ces fonctions. Et tout fonctionne en apparence.

Pour un examen plus approfondi de l'efficacité de cette solution, je testerais les autres scénarios. Mais je manque d'exemples concrets pour les tester (en plus des tests unitaires).

Je pense que readFixed, readF2dot14, readUshorts, readUint64, readASCII, readUnicode, readUTF8, readBytes et readASCIIArray de bin.js de Typr n'auraient pas besoin d'être modifiés car ils n'utilisent pas directement les tableaux typés. Ainsi, seules les fonctions de votre essentiel devraient être modifiées dans Typr. De plus, avec ce changement, le ArrayBuffer partagé de Typr et les tableaux typés deviendront obsolètes.

Si plus de développeurs peuvent tester et donner leur approbation, nous serons encore plus confiants dans la solution. C'est parce que j'ai un nombre limité de cas de test et d'appareils de test à ma disposition et il y a une petite chance que le résultat du test soit biaisé.

Votre solution proposée semblait prometteuse, je viens donc de la tester et devinez quoi, elle fonctionne également (sur tous les navigateurs que j'ai énumérés précédemment) !
L'utilisation de DataView semble être un moyen concis et approprié d'implémenter cela dans JS si vous me le demandez. Joli.

Étonnante!!! Je peux à peine le croire. 🎉 🥳

Je vais faire quelques tests supplémentaires pour voir si je peux valider les autres fonctions et faire une comparaison de performances de base. À moins que quelque chose de méchant n'apparaisse, je l'intégrerai dès que possible. Je suis assez confiant pour inclure cela dans une version en trois textes de la troïka afin que les gens puissent l'essayer; la communauté nous fera savoir si des problèmes surviennent avec elle. Une fois qu'il sera sorti un peu dans la nature, je le soumettrai en amont à Typr.

Les performances semblent comparables, voire un peu plus rapides dans certains cas. Gain supplémentaire ! 😄

J'ai vérifié que les autres fonctions fonctionnent aussi. J'ai dû modifier légèrement l'assistant _view pour gérer les cas dans les polices CFF où Typr passe buff comme un tableau JS simple plutôt qu'un Uint8Array.

J'ai publié la version troika-three-test 0.43.1-alpha.0 avec le correctif DataView (utilisant actuellement un fork privé de Typr - relevant commit )

Quiconque en est capable (@amitrajput1992? @strangerintheq? @atlmtw?), j'apprécierais grandement de tester cette version pour vérifier qu'elle corrige le problème dans vos applications spécifiques. Je vais essayer de faire la même chose avec Browserstack ou trouver un iPhone à emprunter. Merci d'avance!

Hey @lojjic c'est bon d'entendre qu'il y a un correctif pour ça. Laissez-moi tester ça rapidement et reviens vers vous.

@amitrajput1992 Bonjour, avez-vous déjà eu l'occasion de tester l'alpha ? Je veux que cela soit publié et j'aimerais la validation supplémentaire. :)

@lojjic Hey, j'ai juste le temps de tester ça. ça a l'air de fonctionner maintenant !!

Vérifiez les changements ici : https://amitrajput1992.github.io/r3f-experiments/?path=/story/testers --text-tester

J'ai publié la version 0.44.0 avec le correctif pour ce vilain bogue. Je suis si heureux d'avoir enfin réglé ce problème ! Merci à tous pour votre aide, et en particulier @malulleybovo pour avoir creusé profondément là où j'étais incapable et trouvé la cause première. Je suis très reconnaissant ! 🥳