Pixi.js: 제안: 텍스트 렌더링 개선

핵심이 아니어야 합니다.
이것은 무거운 패키지이고 반드시 메인 패키지 외부에서 구현되어야 하므로 핵심 팀은 구현에 대해 걱정할 필요가 없습니다.

Pixi SDF가 올바른 예입니다.

Plz, PIXI에서 Phaser를 만들지 마십시오.

좀 더 맥락을 주고 싶습니다. 나는 @SukantPal 에게 서로 다른 절충안이 있는 대체 Text/BitmapText 접근 방식을 연구하도록 요청

여기에는 여러 가지 접근 방식이 있다고 생각합니다. 일부는 제3자 플러그인으로 적절할 수 있고, 일부는 리포지토리에 있지만 번들로 제공되지 않을 수 있으며, 일부는 현재 API를 대체/증가할 수 있습니다. 가장 유익한 텍스트 렌더링 접근 방식이 성능을 최적화하지만 BitmapText에 대한 절충안이 더 적은 것이 무엇인지 알아보겠습니다.

좋은 텍스트 표시 개체를 판단하는 데 사용할 몇 가지 기준이 있습니다.

• 우수한 런타임 성능 - 텍스트 렌더링 및 텍스트 변경 비용이 저렴합니다.
• 메모리 부족 - RAM 사용량이 낮습니다.
• 작은 종속성 - 종속성 풋프린트 파일 크기가 작습니다.
• 뛰어난 충실도 - 다양한 해상도에서 잘 작동합니다.
• 유연한 스타일링 - 획, 그림자, 그라디언트 지원
• 큰 글리프 언어 지원 - 예, 중국어, 일본어, 한국어
• 이전 버전과 호환 - Context2D와 함께 작동

| | 성능 | 메모리 | 종속성 | 충실도 | 스타일링 | 한중일 | 컨텍스트 2d |
|--|--|--|--|--|--|--|--|
|텍스트| 👎 | 👎 | 👍 | 👍 | 👍 | 👍 | 👍 | 👍 |
|비트맵텍스트| 👍 | 👎 | 👍 | 👎 | 👎 | 👎 | 👍 |

확인.
fragment interpolation 및 모든 비네이티브 구현에 대해 설명합니다.

1. 추가 셰이더와 추가 데이터가 필요합니다. 그러면 일괄 처리가 방지됩니다.
2. 변경 시 지오메트리를 다시 작성해야 합니다(p.3).
3. 스트리밍을 지원할 수 없기 때문에 특정 TTF를 완전히 메모리에 로드해야 하는 언어에 존재하는 모든 글리프에 대해 글리프 테이블이 필요하고 이를 구문 분석합니다. SWF처럼 보입니다.
   시스템 글꼴을 모양으로 로드할 수 없기 때문에 사용할 수 없습니다.
4. 언어별 규칙은 ltr/rtl, 힌디어/아랍 문자 연결 규칙 등 렌더 규칙을 구현하는 브라우저 팀에서 lib 팀으로 이동하고 있습니다. 이는 10% 브라우저를 lib로 이동하는 것과 같습니다. Unity는 아직 제대로 구현하지 않았습니다.
5. 지원 스타일에 대한 추가 인수가 있는 무거운 셰이더. 실시간으로 렌더링해야 하므로 렌더링 비용이 증가합니다.
   물론 텍스처로 캐시해야 합니다.

@eXponenta

• 텍스트는 일괄 처리될 수 있지만 그래픽과 같은 다른 항목은 그렇지 않습니다.

• 현재 텍스트 구현은 각 글리프를 여러 번 캐시합니다(한 문자가 여러 PIXI.Text에서 여러 번 사용되는 경우). 글리프당 하나의 지오메트리가 있는 것이 더 좋습니다. 또한 다른 글꼴 크기로 캐시할 필요가 없습니다.

• 기하학은 말마다 다시 작성할 필요가 없습니다. 텍스트의 문자가 변경되면 글리프 기하학 테이블에서 다시 가져와야 합니다. 변형이 변경되면 유니폼 하나만 변경하면 됩니다.

• 글꼴 구문 분석을 위해 라이브러리를 사용할 수 있습니다. 기하학으로의 변환은 간단합니다.

• 글리프 연결 규칙이 무엇인지 모르겠습니다. 설명해 주시겠습니까?

• 왼쪽에서 오른쪽 대 오른쪽에서 왼쪽 - 문자를 반대로 하려면 할 수 있습니다. 미러 이미지를 원하면 내부적으로 scale.x=-1 를 설정합니다.

• 텍스트 스타일은 셰이더에 더 많은 인수를 추가하지 않습니다. 지오메트리를 변경합니다. 이제 글리프를 지오메트리로 저장하는 것은 텍스처에 캐싱하는 것보다 _적은_ 메모리를 사용합니다.

• API에서 가져온 글꼴 파일은 사용자 컴퓨터에 캐시되어야 합니다.

U 매우 순진한:

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 와 동일한 문제이므로 외부 종속성을 사용할 수 없습니다.
코어는 깨끗해야 합니다. 최소한의 외부 종속성.

@eXponenta

• 혼합 레이아웃(ltr 및 rtl 결합)은 고성능보다 우선 순위가 낮습니다. 항상 현재 알고리즘으로 대체할 수 있습니다. 데바나가리와 비슷합니다. 그래디언트 스톱과 같은 특수 기능도 폴백이 필요합니다.

• 텍스처가 없으면 배치가 더 쉽기 때문에 여기서 일괄 처리할 수 있습니다. CanvasGraphicsRenderer 와 같은 플러그인을 만들 수 있습니다.

확인. 유 승리. 해. 그러나 핵심 외부에서 우리는 그것을보고 그때 우리가해야 할 일을 결정할 것입니다.
그러나 큰 의존성은 없습니다.

@eXponenta 제발 너무 적대적

@eXponenta 지금 오른쪽에서 왼쪽으로

우리가 생각하고 있는 또 다른 접근 방식은 캔버스 2D(현재와 동일)를 사용하여 각 글리프를 별도로 렌더링하고 아틀라스에 캐시하는 것입니다. 아틀라스는 모든 PIXI.Text 인스턴스에 대해 전역적으로 재사용할 수 있습니다. 각 글리프 + 글꼴 크기 + 글꼴 스타일 조합은 별도로 캐시됩니다.

그것을 핵심으로 받아들이는 것에 대해 어떻게 생각하세요?

여러분, 테이블에서 이러한 새로운 접근 방식을 듣게 되어 정말 기쁩니다. @eXponenta , 일으키며 건설적으로 유지합시다. 당신은 분명히 새로운 제안된 접근 방식에 대한 좋은 통찰력을 가지고 있지만 제기된 문제를 완화하고 친근하게 유지할 수 있는지 확인하는 것을 목표로 합시다. :)

문자로 여기 내 2센트(펜스?)..

개인적으로 가장 가치 있는 접근 방식은 비트맵 텍스트의 속도와 성능을 얻는 것이지만 실제로 미리 비트맵 글꼴을 만들 필요가 없는 것입니다. 원한다면 동적 비트맵 텍스처 구축!

동적 비트맵 글꼴

프로

• 비트맵 글꼴을 만들기 위한 도구는 거의 없습니다! 그 장벽을 없애고 싶습니다.
• 다양한 크기의 텍스트 크기 텍스처를 만들 수 있습니다.
• 캔버스와 함께 작동
• 각 글리프의 성능을 일괄 처리할 수 있습니다.
• 멋진 효과를 많이!
• API는 약간만 조정하면 됩니다.

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


const bitmapFont = new BitmapFont(textStyle);

단점

• 비트맵 현재 비트맵 글꼴의 다른 모든 단점:P
• 텍스처 아틀라스를 동적으로 업데이트하면 속도가 느려집니까?
  
  
  
  • 이것은 잠시 후 안정화되고 세션 간에 캐시될 수 있습니까?
  
  
  • 현재 텍스트는 프레임이 변경될 때마다 텍스처를 업로드해야 합니다. 이 접근 방식은 작업을 덜 수행할까요?
  
  

아이디어

• localstorage에서 생성된 텍스처를 캐시할 수 있습니까? 다음 방문을 위해?
• 사용된 문자만 추가하면 텍스처가 필요한 만큼 커집니다. 진행하면서 업데이트
• 추가로 멋진 효과(윤곽, 그림자 등)를 위해 이 텍스처에 필터를 적용합니다.
• 각 글리프를 스프라이트로 만들지 않음으로써 비트맵 글꼴의 메모리를 줄일 수 있습니까?

자위대
SDF는 위의 접근 방식의 확장이 될 수 있습니까? 그 텍스처를 동적으로 생성하는 것은 얼마나 복잡할까요? 슈퍼 젠키가 될까요? 코드 기반을 크게 늘리고 있습니까?

대부분의 사람들은 그것이 무엇인지 알지 못하므로 이상적으로는 숨겨야 합니다. 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 , 당신은 지금 저보다 이 아이디어에 더 가깝습니다. 그래서 제 걱정에 대해 의견을 듣고 싶습니다!

그렇긴 하지만, 우리의 생각을 검증하기 위해 테스트할 수 있는 프로토타입을 만들 가치가 있지 않을까요?

텍스트의 신나는 시간 :D

SDF는 위의 접근 방식의 확장이 될 수 있습니까? 그 텍스처를 동적으로 생성하는 것은 얼마나 복잡할까요? 슈퍼 젠키가 될까요? 코드 기반을 크게 늘리고 있습니까?

SDF 생성은 비용이 많이 들고 패킹 시간이 있지만(아틀라스에서 다른 글꼴을 패킹할 때) 클라이언트에서 캐시할 수 있습니다(다른 모든 변형과 마찬가지로).
캔버스 (헤헤) 구현이 있습니다.
https://github.com/mapbox/tiny-sdf
그러나 SDF 컴파일이 완전히 정확하지 않습니다(글꼴 크기를 늘리거나 줄일 때 글리프 변경).
유용해 보이지만 MSDF의 경우 채널당 3번 실행해야 합니다.

오 와우, 그것은 약간의 코드입니다! 셰이더도 하기에는 무르익은 것 같습니다!

@GoodBoyDigital tiny-sdf 패키지는 단일 채널 거리 필드를 생성합니다. 더 작은 글꼴 크기로 텍스트를 캐시하면 날카로운 모서리가 생성되지 않습니다. 이는 렌더링되는 동일한 글꼴 크기로 캐싱하여 완화할 수 있습니다.

단일 채널 SDF 생성도 나쁘지 않습니다. 다중 채널 SDF는 너무 복잡하다는 점을 제외하고는 우수합니다. Chumskly가 모서리를 인코딩하는 방법을 이해할 수 없었습니다.

이제 우리가 고려하고 있는 모든 것은 rtl 및 Ltr 레이아웃 혼합을 지원하지 않습니다( @eXponenta 가 올바르게 지적한 대로). 하지만 현재로서는 공식적으로 지원하고 있지 않다고 생각합니다.

정확한 접근 방식에는 두 가지 이점이 있습니다. 작은 캐시 크기(모든 픽셀이 아닌 정점을 캐싱함), "앤티앨리어싱" 설정이 꺼져 있는 경우에도 앤티앨리어싱(텍스트는 항상 앤티앨리어싱될 것으로 예상됩니다. 현재 구현은 캔버스를 사용하여 수행합니다. 2D).

데모와 관련하여 제 2차 베지어 곡선 데모를 보셨습니까? https://codepen.io/sukantpal/pen/GRJawBg?editors=0010

——
나와 @bigtimebuddy 가 가장 간단한 솔루션으로 논의한 또 다른 사항은 캔버스 2D를 계속 사용하고 글리프를 텍스처에 캐시하는 것입니다. 글리프는 쿼드로 렌더링할 수 있습니다. 캐시 아틀라스는 텍스트 간에 재사용할 수 있습니다. 물론 이것은 큰 텍스트가 동일한 크기로 캐시되고 따라서 많은 텍스트가 렌더링되지만 그 일부(PDF의 현재 페이지와 같은)만 표시될 때 큰 메모리 사용량을 의미합니다.

멋진,

예, 현재 방법을 통해 항상 사용할 수 있는 rtl 또는 ltr에 대해 걱정할 필요가 없으며 모든 사용자 지정 텍스트 렌더링 기술이 나중에 해결해야 하는 문제입니다.
이러한 결정. 이상적으로는 메모리 소비와 런타임 성능에 중점을 두어야 합니다.

베지어 데모는 훌륭하지만 전체 문장을 렌더링할 때 숨겨질 수 있는 진정한 복잡성을 이해하는 데 충분하지 않다고 생각합니다.

위에서 동적 비트맵 글꼴에 대해 쓴 내용은 글리프 캐싱에 대해 언급한 내용과 거의 동일합니다. 내려갈 때 확실히 유용한 루트라고 생각합니다!

요약하자면:

베지어 곡선 솔루션: 이것은 좋은 경로일 수 있지만 실제 프로덕션 사용 사례에 어떻게 맞는지 파악하려면 추가 R&D가 필요하다고 생각합니다.

일반 글꼴의 동적 비트맵 글꼴: 이것은 API를 단순하게 유지하면서 좋은 성능을 제공한다는 것을 알고 있으므로 확실히 탐색해야 합니다. 내가 좋아하는 :D

단일 채널 SDF 좋은 다중 채널 SDF가 되지는 못하지만 데모는 꽤 좋아 보였습니다! 텍스트가 잘 확장되고 글꼴당 하나의 텍스처를 가질 수 있다면 이 경로도 조사할 가치가 있다고 생각합니다!

@GoodBoyDigital 나는 데모에 꽤 좋은 텍스트가 있다고 생각합니다. 그러나 세부 사항을 찾으려면 눈에 띄는 차이점이 있습니다.

상단의 텍스트는 날카롭지 않습니다. 가장자리가 흔들립니다. 각 글꼴+(글꼴 크기의 ~12-15px 차이) 조합은 별도로 캐시해야 할 수 있습니다.

흔들림이 중요하지 않거나 여러 글꼴 크기에서 캐싱을 사용할 수 있다면 SDF를 사용하는 것이 좋습니다.

가장 간단한 솔루션도 저에게는 괜찮습니다 💯tbh!

모두 안녕.

저는 Pixi에 관한 모든 것을 아는 초심자이지만, Pixi를 백엔드로 사용하는 GDevelop의 사용자입니다. 그리고 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/

누군가가 GDevelop용 Pixi Text 확장을 수정할 수 있기를 바랐기 때문에 실제로 이 문제에 대한 현상금이 있습니다.

이 방법에 잠재적인 문제가 있는지 알 수 없지만 sdf/msdf/etc의 모든 성능 문제를 피하는 것 같습니다.

@Silver-Streak 텍스트 표시 개체에 적용된 축척으로 글꼴 크기를 늘리는 것을 의미한다면 성능 면에서 어떻게 더 나을까요? SDF 항목은 더 큰 글꼴 크기로 다시 렌더링하지 않기 때문에 성능에 도움이 됩니다.

@Silver-Streak 물론, 당신의 제안은 _품질_을 향상시킬 것이지만 그것이 어떻게 성능을 향상시킬지는 모르겠습니다.

@Silver-Streak 물론, 당신의 제안은 _품질_을 향상시킬 것이지만 그것이 어떻게 성능을 향상시킬지는 모르겠습니다.

내가 오해하지 않는 한, 글꼴 크기를 변경하면 전체 개체의 크기를 조정하거나 다른 렌더러에서 로드하는 것보다 리소스를 덜 사용하지 않을까요? 다시 말하지만, 저는 Pixi의 크기 조정이 실제로 작동하는 방식에 관해서는 매우 평범한 사람입니다. 글꼴을 기본 해상도로 유지하지만 텍스트 크기를 변경하는 것이 크기를 조정하는 것보다 빠를 것이라는 것이 이해가 되었습니다. 그것이 옳지 않다면, 주의를 산만하게 한 것에 대해 사과하십시오.

@Silver-Streak Scaling은 변환으로 구현됩니다. 변환 행렬이 있으며 해당 행렬의 배율을 변경하는 것은 간단한 작업입니다.

현재 텍스트는 Canvas 2D API를 사용하여 캔버스에 렌더링됩니다. 그런 다음 화면에 복사됩니다. 배율을 변경하면 캔버스의 텍스트가 매핑되는 화면 좌표만 변경됩니다.

아, 말이 되는군요. 불행히도 제 문제는 글꼴의 그래픽 렌더링이 크기가 조정된 후 흐릿해지는 문제가 더 많지만 성능도 더 좋을 것이라고 생각했습니다.

다른 사람이 일반적인 텍스트 품질 문제를 해결하기 위해 이를 구현하면 좋겠지만 성능을 개선하려는 마음도 충분히 이해할 수 있습니다.

저와 함께 이야기해주셔서 감사합니다.

@Silver-Streak 문제 없습니다. 그러나 품질 우선 텍스트를 구현하는 것은 WebGL에서도 어렵지 않아야 합니다. 일부 응용 프로그램은 자체적으로 메쉬를 만들어 텍스트를 구현합니다. 글꼴 파일을 구문 분석하고 정점 목록을 만들고 테셀레이션할 수 있습니다. 이러한 정점은 메쉬를 통해 렌더링될 수 있습니다.

높은 축척에서는 약간의 "가장자리"가 발생할 수 있습니다. 왜냐하면 궁극적으로 텍스트를 삼각형으로 렌더링하기 때문입니다. 더 높은 품질을 위해 이 스레드에서 이야기한 "정확한 베지어 곡선" 셰이더를 사용할 수 있습니다. 이 셰이더는 곡선을 삼각형이 아닌 곡선으로 렌더링합니다.

텍스트 품질에 대한 도움이 필요하시면 제가 도와드리겠습니다. :)

@SukantPal 저는

그러나 게시물의 문제를 살펴보고 싶다면 Bountysource에서도 이에 대한 현상금이 있으며 모두에게 공개되어 있습니다. 여기에서 더 이상 헤드스페이스를 차지하고 싶지 않습니다. 일반적으로 Pixi에 대해 훨씬 더 깊은 대화가 진행되고 있고 내 제안이 생각만큼 정확하지 않기 때문입니다.

@Silver-Streak 코로나 시즌에 잘할게 없으니 한번 봐야겠다

이것이 닫힌 스레드라는 것을 알고 있지만 모든 사람들이 여전히 텍스트 렌더링을 개선하는 가장 좋은 방법을 찾고 있다고 확신합니다. 나는 누군가가 Pixi v5와 함께 작동하는 msdf 구현을 가지고 있다는 것을 알아차렸습니다. https://github.com/cjsjy123/pixi-msdf-text-v5 관심 있는 사람들에게 언급할 생각입니다.

이 스레드는 확실히 다시 열리고 유지되어야 합니다. 또는 가장 자주 찾는 문제 중 하나이기 때문에 최소한 일종의 업데이트가 자주 있어야 합니다.