Troika: [troika-three-text] IOS Safari 로딩 문제

신고해 주셔서 감사합니다! iOS Safari에서 이와 같은 문제를 설명한 것은 당신이 처음은 아니지만 이전에는 재현할 수 없었습니다. 나는 당신의 사이트를 시도하고 그것을 재현할 수 있기를 바랍니다.

우연히 drei 를 통해 사용하고 있습니까? 아니면 직접?

안녕하세요 @lojjic 이 패키지를 three.js와 함께 직접 사용하고 있습니다. 그리고 제가 3개의 유틸리티를 가지고 있는 이유는 어떤 경우에는 createDerivedMaterial 함수도 사용하기 때문입니다.

확인해주셔서 감사합니다!

iPhone 8에서 웹사이트를 로드하는 문제를 재현할 수 있었습니다. 아직 디버깅을 시작할 시간이 없었지만 버그를 재현할 수 있다는 사실을 알고 싶었습니다.

@atlmtw @lojjic 여러 글꼴을 사용하는 프로젝트의 사파리에서 동일한 문제가 발생했습니다. 내가 찾은 유일한 수정 사항은 이 브라우저의 전체 웹 사이트에서 고유한 글꼴을 사용하는 것이었습니다.

+1
장면당 여러 글꼴 = 일부 글꼴은 iphone X, iphone SE에 표시되지 않습니다.

이 문제를 조사하려고 하는데 지금 재현하는 데 문제가 있습니다. 이전과 동일한 iPhone 8입니다. 나는 더 이상 designdalena.com에서 그것을 재현할 수 없지만, 사이트가 더 이상 troika-three-text를 사용하지 않도록 변경되었거나 다른 방식으로 해결했을 가능성이 있습니다.

그래서 여러 글꼴을 사용하여 최소한의 테스트 케이스를 만들려고 하는데 실패할 수 없습니다.

https://uqgxq.csb.app/

다른 사람이 테스트/디버그에 사용할 수 있는 어딘가에서 이것을 재현할 수 있습니까?

안녕하세요 @lojjic

확인을 위해 다른 것으로 변경했습니다. 나는 트로이카를 더 많이 사용하는 경험을 즐긴다.

@atlmtw 확인해주셔서 감사합니다. 나에게 보낼 수 있는 소스 제어에 사이트의 이전 버전이 있다고 생각하지 않습니까? 나는 이것을 재현하기 위해 고군분투하고 있으며 당신의 것은 믿을만한 재현처럼 보였습니다.

안녕하세요 @lojjic
이것에 행운이 있습니까? iPhone(iPad 및 macOS에서 작동)에서 >1 글꼴이 사용될 때도 이것을 보았습니다. 이상하게도 이것은 항상 복제할 수 없으며 1-2/10번만 발생하며 첫 번째 로드에서만 발생합니다. 글꼴 파일 다운로드와 관련이 있습니까?

Btw, 일을 사랑하십시오 :100:

@amitrajput1992 아니요, 여전히 재현 가능한 테스트 케이스를 구성할 수 없었습니다. 내가 사용할 수있는 하나가 있습니까?

@lojjic
이것을 시도?
데스크탑에서 열면 서로 다른 색상으로 인쇄된 6개의 다른 텍스트가 표시됩니다.
나는 나와 함께 몇 대의 장치에서 이 링크를 테스트했고 BrowserStack에서 몇 대는 모두 렌더링 문제를 보여줍니다. 링크를 몇 번 새로 고치면 작동하는데 매우 이상합니다.

이것이 내가 BrowserStack에서 본 것입니다. 이것은 아이폰 8 + 사파리 v13에 있습니다

이것은 내 iPhone 11 + Safari 14에서

웹 작업자에서 글꼴 파일을 다운로드한다는 사실과 관련이 있습니까? 우리는 사파리가 웹 작업자에게 고통을 줄 수 있다는 것을 알고 있습니다.

@amitrajput1992 감사합니다. 실제로 해당 페이지에서 문제를 복제할 수 있습니다. 거기에서 디버그할 수 있는지 및/또는 최소화된 로컬 테스트 케이스에서 복제할 수 있는지 확인하겠습니다.

우리는 사파리가 웹 작업자에게 고통을 줄 수 있다는 것을 알고 있습니다.

다른 사람들도 그렇게 말하는 것을 들었고 작업자를 사용하는 것이 확실히 그럴듯한 범인이지만 Safari에서 작업자의 알려진 버그에 대한 세부 정보를 찾을 수 없었습니다. 공유할 수 있는 구체적인 내용이 있습니까?

@lojjic
그 좋은 소리. 어떤 식으로든 도움이 된다면 알려주세요. 한편, 나는 디버깅을 계속하고 문제의 범위를 좁히려고 노력할 것입니다.

다른 사람들도 그렇게 말하는 것을 들었고 작업자를 사용하는 것이 확실히 그럴듯한 범인이지만 Safari에서 작업자의 알려진 버그에 대한 세부 정보를 찾을 수 없었습니다. 공유할 수 있는 구체적인 내용이 있습니까?

여기에서 정확한 문제에 대해 알지 못합니다. 부분적으로는 이러한 문제를 어디에서나 찾을 수 없기 때문입니다(또는 사람들이 기록하지 않음). 하지만 이것은 제가 만지작거리는 동안 알아차린 것입니다. react360은 웹 작업자 내부에서 전체 반응 코드를 실행하는 데 사용되었던 이전 react-vr(지금은 폐기됨)이었고 메인 스레드에 대한 업데이트가 너무 느렸습니다. 작업자 스레드에서 내 클릭 수신기로 전파하기 위해 약 300ms에서 500ms 사이의 어느 곳에서나 클릭 작업을 쉽게 수행할 수 있으며 종종 몇 번의 클릭도 놓칠 수 있습니다.
나는 3개의 gif 렌더러인 repo를 유지 관리하고 처음에는 오프스크린 캔버스로 시도했지만 결과는 끔찍했고 연속 프레임에서 텍스처가 혼합되었습니다. 전체를 메인 스레드로 옮기면 크게 개선되었습니다.

나는 이것이 작업자에서 메인 스레드로 정보를 전송할 때 사용되는 구조화된 복제 알고리즘과 관련이 있을 수 있다고 생각합니다. iOS에서 이 제한 사항에 대한 확실한 증거를 찾지 못했지만

항상 나타나지는 않지만 가끔 나타나는 이러한 아티팩트에 먼저 집중해야 한다고 생각합니다.

이러한 경우 레이아웃 및 SDF 생성이 분명히 완료되고 기본 스레드로 돌아가지만 일부 SDF는 내부/외부 채우기가 제자리에서 반전된 것으로 보입니다. 경로 세그먼트가 절반만 있는 것처럼 해당 문자에 대한 경로 데이터가 불완전한 경우 어떻게 발생할 수 있는지 알 수 있습니다.

글꼴 로드 중에 글꼴의 배열 버퍼가 잘리거나 손상된 경우 문제가 발생하면 이러한 현상이 나타날 수 있다고 생각합니다. 마찬가지로 특정 위치에서 잘리면 완전히 비어 있는 결과가 나올 수도 있습니다.

가능성으로 조사하겠습니다(어쩌면 XHR이 부분적인 arraybuffer 응답을 제공합니까?). 그러나 첫 번째 단계는 이것을 수정하고 로컬에서 실행할 수 있는 재현 가능한 테스트 케이스로 가져오는 것입니다.

그것은 의미가 있습니다. 어레이 버퍼 손상이 여기에서 범인일 수 있습니다.
이 전체 프로세스를 메인 스레드에서 실행하는 것에 대한 또 다른 토론을 보았습니다. 그것이 로드맵에 있습니까?

또한 도움이된다면 아래 버전에서 drei를 사용하여 troika를 사용하고 있습니다.
@react-3/섬유: 6.2.3
@react-three/drei: 6.0.1
트로이카: 0.42.0
3: 0.129.0

메인 스레드에서 실행하는 것은 가능하지만 잠재적으로 몇 초 동안 메인 스레드를 차단하는 꽤 형편없는 경험을 하게 될 것입니다. 그것은 최후의 수단일 뿐입니다.

테스트 페이지가 변경되었습니까? 적어도 iOS에서는 이제 모든 다른 텍스트 개체에 대해 단일 글꼴만 사용하는 것 같습니다...? 나는 여전히 가끔 그 단일 글꼴로 왜곡된 SDF를 봅니다. 이는 이것이 여러 글꼴로 인해 악화될 수 있지만 이에 국한되지 않음을 의미합니다.

전체 앱에 대해 단일 글꼴만 사용하도록 iOS 기기에 대한 대체를 추가했습니다. 이것은 내 생산 환경이므로 거기에 문제가 있을 수 없습니다.
내 스테이징 환경에서 다른 예를 만들고 최대한 빨리 여기에 링크를 보내겠습니다.

이것이 여전히 단일 글꼴에서도 발생한다는 것을 알아내는 것은 번거롭습니다.facepalm:

흠 실제로 Safari devtools에 연결될 때 새 단일 글꼴에서만 버그가 발생하는 것 같으며 꽤 일관되게 버그가 발생했습니다. 그것이 우리에게 어떤 단서를 제공하는지 확실하지 않습니다.

글쎄, 조금 더 진행... 나는 개별 글리프에 대한 경로 명령을 잘라내어 위에서 본 것과 동일한 부분 글리프 아티팩트를 강제할 수 있음을 확인했습니다. 원래 글꼴 데이터가 불완전하기 때문인지(많은 부분이 아닌 하나의 부분 글리프만 발생시킬 것이라고 생각합니다. 그래서 그럴 가능성은 거의 없습니다), 아니면 무엇인가 for-loop가 일찍 종료하십시오(불가능해 보이지만 이상한 JIT 버그가 있을 수 있음).

어느 쪽이든, Safari의 USB 연결 devtools가 관련 코드에서 중단점을 설정할 수 없다는 문제가 발생했습니다. @amitrajput1992 테스트 앱을 로컬에서 빌드/실행할 수 있는 소스 파일로 가져오는 것이 가능합니까? 그래서 디버그할 트로이카 코드를 교체해 볼 수 있습니까?

@lojjic 원래 앱 코드를 공유할 수는 없지만 프로덕션 앱에서 사용하는 유사한 구조로 스토리북 리포지토리를 설정하고 이에 대한 테스트 렌더를 추가하겠습니다. 곧 링크를 통해 보내드립니다.

@lojjic
내 프로덕션 앱과 유사한 구조로 기본 재현을 설정했습니다. https://github.com/amitrajput1992/r3f-experiments
내 iPhone 11 및 BrowserStack에서 이와 동일한 문제를 복제할 수 있습니다.
또한 쉽게 액세스할 수 있도록 여기에 스토리북을 게시했습니다. https://amitrajput1992.github.io/r3f-experiments

@amitrajput1992 테스트 케이스 주셔서 감사합니다! 스토리북에서 글꼴을 제공하여 gmetri 사이트에서 글꼴을 로드하는 CORS 오류를 수정한 후 복사할 수 있습니다.

그러나 ... 그러면 내 Safari devtools는 연결을 시도하는 _crashes_ 전체를 실행합니다! 🤦🤦🤦🤦🤦🤦 그래서 나는 console.log 문을 추가하고 볼 수조차 없습니다. 이 버그는 정말로 수정되기를 원하지 않습니다. 응?

좌절감; 내일은 좀 더 상쾌한 마음으로 돌아오도록 노력하겠습니다. 아이디어가 있으면 알려주세요.

@lojjic님 , 지금은 mac 시스템이 없지만 로컬 포워딩을 사용하여 브라우저 스택에서 테스트했습니다. 웹 작업자와 메인 스레드 내부에 기록된 sdf 데이터가 다른 것 같습니다. 스레드 통신 간의 직렬화-역직렬화 프로세스 때문일 수 있지만 완전히 확실하지는 않습니다. 나는 이것을 계속해서 디버깅할 것이다.
safari dev-tools가 작동하지 않는 경우 크로스 브라우저 테스트를 시도해 볼 수 있습니다. 100분 평가판을 제공하여 도움이 될 수 있습니다.

관련 코드에서 중단점을 설정할 수 없음

버그를 재현할 수 있기 때문에 코드의 각 줄과 console.log 후에 웹 작업자로부터 메시지를 던지라는 멍청한 제안.

내 iPhone 6/11의 사진:

코드의 각 줄과 console.log 후에 웹 작업자로부터 메시지를 던지라는 멍청한 제안

전혀 멍청한 제안이 아닙니다! 그것이 내가 하려고 했던 것과 정확히 일치하지만 Safari의 devtools는 편집 가능한 로컬 인스턴스를 가리킬 때 즉시 충돌하므로 console.log 출력도 볼 수 없습니다. :(

연결된 iPhone에서 로컬 호스트 URL을 열려고 합니까? 이 경우 포트 포워딩은 어떻게 작동합니까?

연결된 iPhone에서 로컬 호스트 URL을 열려고 합니까? 이 경우 포트 포워딩은 어떻게 작동합니까?

로컬 네트워크 IP 주소를 통해 iPhone에서 개발 서버에 액세스하고 있습니다. 또한 https://localhost.run을 통해 파이핑을 시도했습니다. 두 경우 모두 Safari devtools를 열자 마자 충돌합니다. 페이지 자체는 잘 렌더링됩니다(때로는 버그가 있지만).

몇 가지 블로그에서 이것이 2가지 시나리오에서 발생할 수 있다는 것을 읽었습니다.

1. 휴대폰 배터리가 100%일 때
2. 케이블 연결이 아닌 네트워크를 통해 디버깅할 때

이것은 유사한 라인에서 오래 실행되는 스레드이지만 해결 방법이 없습니다. https://developer.apple.com/forums/thread/92290

그러나 Safari의 devtools는 편집 가능한 로컬 인스턴스를 가리킬 때 즉시 충돌하므로 console.log 출력도 볼 수 없습니다. :(

기본 console.log 기능을 다음과 같이 대체할 수 있습니다.

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

하지만 html 페이지 또는 JS 스크립트에서 해당 div를 만들어야 합니다.

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

이것은 메인 스레드의 모든 콘솔 메시지를 표시해야 합니다.

@munrocket 감사합니다. 작동할 수 있습니다. 시도해 보겠습니다.

모두 안녕,

이 스레드에서 너무 멀리 떨어져 죄송합니다. 이것이 디버깅에 도움이 되는지 알 수 있지만 최근 Xcode 13 버전(베타) 시뮬레이터는 내 3D 로컬 호스트를 잘 실행할 수 있었습니다! 이전 버전과 계속 충돌하는 문제가 발생했습니다.

@lojjic 이것에 행운이 있습니까?

이것에 행운이 있습니까?

아니요, 불행히도 최근에 이에 많은 시간을 할애할 수 없었습니다.

웹 작업자를 끌 가능성이 있습니까? 확인을 위해

여러분, 안녕하세요,

나는 프로젝트(불행히도 코드를 공유할 수 없음)에서 이와 동일한 문제를 우연히 발견했고 결국 바로 여기에서 이 문제 티켓으로 가는 길을 찾았습니다. 이것에 대한 마지막 업데이트가 한 달이 넘었으므로 오늘 정확히 무슨 일이 일어나고 있고 어떤 코드 라인이 이 UX 재앙에 기여하고 있는지 정확히 지적하기 위해 오늘 내 프로젝트의 종속성 코드를 엉망으로 만들기로 결정했습니다.

더 진행하기 전에 아래 정보와 조정은 어떤 식으로든 권장되지 않으며 실제 솔루션을 찾는 데 도움을 주기 위해 여기에 공유된다는 점을 강조하고 싶습니다. 아래 정보는 해결책이 아닙니다. 경고하셨습니다.

첫 번째. 예, 토론의 앞부분에서 언급했듯이 이것은 실제로 iOS Safari의 WebWorker의 특정 문제인 것 같습니다. Firefox(win10), Chrome(win10), Opera(win10), Safari(macOS big sur) 등에서는 이 문제가 발생하지 않으며 글꼴이 100% 제대로 로드됩니다. 그러나 Safari(iOS)는 여러 WebWorker 간에 일종의 경쟁 조건을 실행합니다(이것이 완전히 사실인지 또는 어떤 비동기 호출이 서로 간섭하는지 확인하지 못했습니다).

초. 이 주장된 경쟁 조건(또는 그것이 무엇이든 간에)은 로드되는 글꼴 데이터를 포함하는 버퍼가 Troika의 Typr 종속성에서 readShort 기능을 통해 액세스할 때 몇 개의 NaN 값을 생성하도록 합니다. 그렇다면 문제가 실제로 Typr에 있습니까? 아마도. 확실하지 않습니다. 그러나 이러한 소수의 NaN 값은 호출 스택을 계단식으로 쌓아 문자 그대로 모든 것을 망치고 마침내 문자 모양이 완전히 잘못 표시되도록 합니다.

제삼. 필요한 정확한 위치( Typr/bin.s 의 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];
        return Typr._bin.t.int16[0];
    },

내가 단순히 console.log(Typr._bin.t.int16[0])를 사용했을 때, 응용 프로그램은 절대 있어서는 안 되는 몇 개의 NaN을 인쇄할 것입니다(전체 응용 프로그램이 인쇄 작업을 중단할 수 있으므로 주의해서 시도하십시오. 이 함수가 호출됩니다. 사용 사례에 따라 수천 번). 그러나 예상대로 이 함수 내에서 애플리케이션을 일시 중지하면(디버거 키워드 또는 중단점을 사용하거나 콘솔에 액세스할 수도 있음) 값이 자체적으로 수정되고 NaN이 생성되지 않습니다(경합 조건을 믿게 됨). 즉, 기존 방식으로 디버거를 사용하여 문제를 검사할 수 없습니다.

네 번째이자 마지막으로. 이것은 이 문제에 대한 실제 솔루션을 찾기 위한 목적이 아니라면 반대하는 부분입니다. readShort 함수 내에서 콘솔을 사용하더라도 NaN이 사라진다고 위에서 썼습니다. 그래서 나의 독창적인 해커 사고방식은 readShort의 return 문 앞에 이 스니펫을 포함하는 기발한 아이디어를 생각했습니다.

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 , MacOS Safari를 사용하여 USB를 통한 iOS Safari 디버깅 문제 해결:
MacOS Safari DevTools가 무한 로드를 주장하거나 페이지가 충돌했거나 스크립트를 로드하지 않는 등의 메시지가 표시되는 경우 로컬 네트워크나 휴대전화에 연결을 끊었다가 다시 연결하는 것이 좋습니다. 또는 DevTools를 몇 번 닫았다가 다시 열어보십시오. 그리고 분명히 전화에서 웹 페이지를 새로 고칩니다. 오늘 이런 일이 몇 번(고통) 나고 그렇게(MacOS Big Sur와 iOS 15.0.1 연결) 해결했기 때문에 이 말을 하는 것입니다.

OMG @malulleybovo 휴가에서 돌아와서 당신의 발견을 보았고 와우 정말 놀라운 일이었습니다! 😃 이렇게 찾아주셔서 감사합니다.

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

내 애플리케이션 내의 readShort에서 NaN이 처음 나타나는 것을 엿보는 동안, buff[p]=255 및 buff[p+1]=6(둘 다 유효한 uint8 값)이라는 것을 알았습니다. 이를 염두에 두고 나는 Typr._bin.t.uint8의 값을 엿보았고 예상한 대로 [6, 255, 0, ...]를 발견했습니다. 그런 다음 Typr._bin.t.int16을 살펴보고 [-250, 0, ...] 대신 잘못된 [NaN, 0, ...]을 발견했습니다. 마지막으로 Typr._bin.t.int8을 봤는데... 역시 틀렸습니다... [6, -1, 0, ...]이 아니라 [6, NaN, 0, ...]이었습니다. .

Typr glyf 라이브러리는 다른 유형(Uint8Array, Int8Array, Int16Array 등)의 여러 배열에서 하나의 공유 ArrayBuffer를 사용합니다. 이 발생은 iOS Safari(만 해당)에서 이러한 배열 중 하나를 변경한 후 다른 배열의 값이 즉시 업데이트되지 않을 수 있음을 보여주었습니다. 이유는 알 수 없지만 최근 기록에서 iOS Safari의 ArrayBuffer와 관련된 해결된 버그 보고서를 찾았습니다. 이 보고서는 이것을 더 믿을 수 있게 만듭니다... 한 번 결함이 있는 것으로 입증되었으며 두 번 결함이 있는 것으로 입증될 수 있습니다(참조: (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 사파리(MacOS Big Sur v11.3.1).

*누군가 위의 내 코드 스니펫을 최적화할 수 있다면 자유롭게 해주세요~

결국 이 문제는 트로이카 로 인한 것이 아닌 것 같습니다. 트로이카는 사실 더 깊은 문제의 결과를 겪고 있는 것 같습니다. 그래서 저는 개인적으로 이 문제를 Typr로 옮기겠습니다. 하지만 내가 아는 것은... 직접 테스트하고 이것이 문제의 근본 원인인지 논쟁해 봅시다. ;)

@malulleybovo 는 상을 받을 자격이 있다고 생각합니다! 🥳

범위를 좁히고 문제를 피하는 대체 구현을 생각해 내는 것은 놀라운 일입니다! 정말 감사합니다!

귀하의 readShort 솔루션을 troika의 로컬 재정의 및/또는 Typr의 업스트림으로 통합하게 된 것을 기쁘게 생각합니다. 다른 readFoo 메소드에 대한 대체 구현도 원할 수 있습니까?

일반적으로 typed-arrays-sharing-a-buffer 패턴에 문제가 있거나 위험한 것 같습니다. 지금 생각하면 참 신기한 패턴이다. DataView 는 단위와 JS 숫자 또는 엔디안 불일치 사이의 이상한 값 변환 없이 바이너리에서 다양한 숫자 형식을 읽는 목적으로 정확히 의도된 것 같습니다... 그것도 문제를 해결할 수 있을지 궁금합니다. 아마도 이런 것? https://gist.github.com/lojjic/94d7b5f5f374598fe0e9761be45ebb2b

@lojjic 칭찬 감사합니다~ 도움이 되었다니 다행입니다.

당신이 제안한 솔루션이 유망해 보였기 때문에 방금 테스트해 보고 추측했습니다. 또한 작동합니다(이전에 나열한 모든 브라우저에서)!
DataView를 사용하는 것은 저에게 묻는다면 JS에서 이것을 구현하는 간결하고 적절한 방법인 것 같습니다. 좋은데.

내 응용 프로그램은 Typr의 readInt8, readShort, readUshort 및 readBytes를 사용하는 Typr의 glyf 스크립트에 의존합니다. 테스트 목적으로 전체 솔루션을 포함했지만 이러한 기능에 대해서만 테스트했습니다. 그리고 모든 것은 그것의 외모에 따라 작동합니다.

이 솔루션의 효과에 대해 더 자세히 알아보려면 다른 시나리오를 테스트해 보겠습니다. 그러나 나는 이것들을 테스트할 구체적인 예가 부족합니다(단순한 단위 테스트 외에).

Typr의 readFixed, readF2dot14, readUshorts, readUint64, readASCII, readUnicode, readUTF8, readBytes 및 bin.js의 readASCIIArray는 형식화된 배열을 직접 사용하지 않기 때문에 변경할 필요가 없다고 생각합니다. 따라서 요점의 기능만 Typr 내에서 변경하면 됩니다. 또한 이러한 변경과 함께 Typr의 공유 ArrayBuffer 및 형식화된 배열은 더 이상 사용되지 않습니다.

더 많은 개발자가 이를 테스트하고 승인할 수 있다면 솔루션에 대해 더욱 확신을 갖게 될 것입니다. 내가 사용할 수 있는 테스트 케이스와 테스트 장치의 수가 제한되어 있고 테스트 결과가 편향될 가능성이 적기 때문입니다.

당신이 제안한 솔루션이 유망해 보였기 때문에 방금 테스트해 보고 추측했습니다. 또한 작동합니다(이전에 나열한 모든 브라우저에서)!
DataView를 사용하는 것은 저에게 묻는다면 JS에서 이것을 구현하는 간결하고 적절한 방법인 것 같습니다. 좋은데.

놀라운!!! 나는 그것을 거의 믿을 수 없다. 🎉 🥳

다른 기능의 유효성을 검사하고 기본 성능 비교를 수행할 수 있는지 확인하기 위해 더 많은 테스트를 수행하겠습니다. 불쾌한 일이 발생하지 않는 한 최대한 빨리 통합하겠습니다. 나는 이것을 troika-three-text 릴리스에 포함하여 사람들이 그것을 시도할 수 있도록 매우 자신합니다. 커뮤니티에서 문제가 발생하면 알려줄 것입니다. 일단 야생에서 조금 나오면 Typr에 업스트림으로 제출할 것입니다.

성능은 비슷한 것으로 보이며 경우에 따라 조금 더 빠릅니다. 추가 승리! 😄

다른 기능도 작동하는 것을 확인했습니다. Typr이 Uint8Array가 아닌 일반 JS 배열로 buff 를 전달하는 CFF 글꼴의 경우를 처리하기 위해 _view 도우미를 약간 수정해야 했습니다.

DataView 수정 사항이 포함된 troika-three-test 버전 0.43.1-alpha.0 을 게시했습니다(현재 Typr 관련 커밋 의 개인 포크 사용)

(@amitrajput1992? @strangerintheq? @atlmtw?) 능력이 있는 사람이라면 이 버전으로 테스트하여 특정 응용 프로그램의 문제를 해결하는지 확인해 주시면 감사하겠습니다. 나는 Browserstack을 사용하거나 빌릴 iPhone을 찾아 동일한 작업을 시도할 것입니다. 미리 감사드립니다!

@lojjic 이 문제에 대한 수정 사항이 있다는 소식을 듣게 되어 기쁩니다. 빨리 테스트해보고 다시 연락드리겠습니다.

@amitrajput1992 안녕하세요, 아직 알파를 테스트할 기회가 없었나요? 나는 이것을 릴리스하고 추가 검증을 원합니다. :)

@lojjic 안녕하세요, 방금 이것을 테스트할 시간이 생겼습니다. 이제 작동하는 것 같습니다!!

여기에서 변경 사항을 확인하십시오: https://amitrajput1992.github.io/r3f-experiments/?path=/story/testers --text-tester

이 불쾌한 버그를 수정한 0.44.0 버전을 출시했습니다. 드디어 해결되어서 너무 기쁩니다! 도움을 주신 모든 분들께 감사드립니다. 특히 @malulleybovo 가 제가 할 수 없는 부분을 깊이 파고들어 근본 원인을 찾아주셔서 감사합니다. 정말 감사합니다! 🥳