Pixi.js: 提案：テキストレンダリングの改善

コアにあるべきではありません。
これは重いパッケージであり、メインパッケージの外部に実装する必要があります。コアチームは、その実装について心配する必要はありません。

PixiSDFはその正しい例です。

Plz、PIXIからPhaserを作成しようとしないでください

もう少しコンテキストを説明したいと思います。 @SukantPalに、さまざまなトレードオフを持つ代替のText / BitmapTextアプローチを調査するように依頼しました。 特に、テキストよりもパフォーマンスが高く、見栄えのするものを見つけることができれば。

ここにはいくつかのアプローチがあると思います。 サードパーティのプラグインとして適切なものもあれば、リポジトリに含まれているがバンドルされていないものもあり、現在のAPIを置き換え/拡張するものもあります。 パフォーマンスを最適化するが、BitmapTextとのトレードオフが少ない、最も有益なテキストレンダリングアプローチを理解しましょう。

良いテキスト表示オブジェクトを判断するために使用する基準がいくつかあります。

• 優れたランタイムパフォーマンス-テキストのレンダリングとテキストの変更は低コストです
• 低メモリ-RAM使用量が少ない
• 小さな依存関係-依存関係のフットプリントファイルサイズが小さい
• 優れた忠実度-さまざまな解像度でうまく機能します
• 柔軟なスタイリング-ストローク、ドロップシャドウ、グラデーションのサポート
• 大きなグリフ言語をサポート-例：中国語、日本語、韓国語
• 下位互換性-Context2Dで動作します

| | パフォーマンス| メモリ| 依存関係| 忠実度| スタイリング| CJK | Context2d |
|-|-|-|-|-|-|-|-|
|テキスト| 👎| 👎| 👍| 👍| 👍| 👍| 👍| 👍|
|ビットマップテキスト| 👍| 👎| 👍| 👎| 👎| 👎| 👍|

Ok。
fragment interpolationとすべての非ネイティブ実装について説明します。

1. 追加のシェーダーと追加のデータが必要です-それはバッチ処理を防ぎます。
2. 変更時にジオメトリを再構築する必要があります（p.3）。
3. 言語に存在するすべてのグリフにグリフテーブルを要求します。otはストリーミングをサポートできないため、特定のTTFをメモリに完全にロードする必要があり、それを解析します。 SWFのように見えます。
   システムフォントを図形として読み込むことができないため、使用できません。
4. 言語固有のルールは、ブラウザチームからlibチームに移動し、レンダリングルールを実装します：ltr / rtl、ヒンディー語/アラビア語のグリフ連結ルールなど... 10％のブラウザをlibに移動するのと同じです。 Unityはまだそれを実装していませんでした。
5. スタイルをサポートするための追加の引数を持つヘビーシェーダー。 リアルタイムでレンダリングする必要があるため、レンダリングコストが増加します。
   そしてもちろん、テクスチャとしてキャッシュする必要があります。

@eXponenta

• テキストはバッチ処理できますが、グラフィックスなどの他のものではバッチ処理できません。

• 現在のテキスト実装は、各グリフを複数回キャッシュします（文字が複数のPIXI.Textで複数回使用されている場合）。 グリフごとに1つのジオメトリを使用する方が適切です。 また、異なるフォントサイズでキャッシュする必要はありません。

• ジオメトリを再構築する必要はありません。テキスト内の文字が変更された場合は、グリフジオメトリテーブルから再度フェッチする必要があります。 変換が変更された場合は、1つのユニフォームを変更するだけです。

• フォント解析にライブラリを使用できます。 ジオメトリへの変換は簡単です。

• グリフ連結規則が何であるかわかりません。 説明してもらえますか？

• 左から右vs右から左-文字を逆にしたい場合は、できます。 鏡像が必要な場合は、内部でscale.x=-1設定します。

• テキストのスタイル設定では、シェーダーに引数が追加されません。 ジオメトリが変更されます。 現在、グリフをジオメトリとして保存すると、テクスチャにキャッシュするよりもメモリが少なくて済みます。

• APIからフェッチされたフォントファイルは、ユーザーのマシンにキャッシュする必要があります。

非常に素朴です：

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ようなプラグインを作成できます。

Ok。 Uが勝ちます。 やれ。 しかし、コアの外側では、それを調べて、次に何をすべきかを決定します。
しかし、大きな依存関係はありません。

@eXponentaはそんなに敵対的であることをやめてください。 私たちは、まだ何もしっかりしていないアプローチを模索しています。 建設的であり、侮辱を使用しないでください。

@eXponenta現在、右から左へのテキストをサポートしていますか？

私たちが考えているもう1つのアプローチは、キャ​​ンバス2D（現在と同じ）を使用して各グリフを個別にレンダリングし、それらをアトラスにキャッシュすることです。 アトラスは、すべてのPIXI.Textインスタンスでグローバルに再利用できます。 各グリフ+フォントサイズ+フォントスタイルの組み合わせは個別にキャッシュされます。

それをコアに受け入れることについてどう思いますか？

ちょっと覗いて、これはテーブルでこれらの新しいアプローチを聞くのは本当にエキサイティングです。 @eXponentaは、@bigtimebuddyエコー、のは建設的なことをしてくださいキープしましょう。 あなたは明らかに、新しく提案されたアプローチについていくつかの良い洞察を持っていますが、提起された問題を軽減し、それを友好的に保つことができるかどうかを確認することを目指しましょう:)

テキストでは、ここに私の2セント（ペンス？）があります。

個人的には、ビットマップテキストの速度とパフォーマンスを向上させることが最も価値のあるアプローチだと思いますが、事前に実際にビットマップフォントを作成する必要はありません。 必要に応じて、動的なビットマップテクスチャの構築！

動的ビットマップフォント

プロ

• ビットマップフォントを作成するためのツールはほとんどありません。 その障壁を取り除きたいです。
• さまざまなサイズのテキストサイズのテクスチャを作成できます。
• Canvasで動作します
• 各グリフをバッチ処理できるパフォーマンス
• クールな効果がたくさん！
• APIはわずかな調整のみが必要です。

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


const bitmapFont = new BitmapFont(textStyle);

短所

• ビットマップの現在のビットマップフォントの他のすべての短所：P
• テクスチャアトラスを動的に更新すると速度が低下しますか？
  
  
  
  • これはしばらくすると安定しますが、セッション間でキャッシュされる可能性がありますか？
  
  
  • 現在のテキストは、フレームを変更するたびにテクスチャをアップロードする必要がありますが、このアプローチではそれが少なくなりますか？
  
  

アイデア

• ローカルストレージで生成されたテクスチャをキャッシュできますか？ その後の訪問のために？
• 使用する文字のみを追加するため、テクスチャは必要なだけ大きくなります。 更新していきます
• フィルタをこのテクスチャに焼き付けて、さらにクールな効果（アウトライン、シャドウなど）を実現します。
• 各グリフをスプライトにしないことで、ビットマップフォントのメモリを削減することができますか？

自衛隊
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の生成にはコストがかかり、パッキング時間もありますが（アトラスにさまざまなフォントをパックした場合）、クライアントにキャッシュできます（他のすべてのバリアントと同様）。
それのキャンバス（hehe）実装があります：
https://github.com/mapbox/tiny-sdf
ただし、SDFコンパイルは完全には正しくありません（フォントサイズを増減するとグリフが変更されます）
便利そうに見えますが、MSDFの場合は3回（チャネルごとに）実行する必要があります。

わあ、それはほんの少しのコードです！ シェーダーも実行するのに熟しているように見えます！

@GoodBoyDigital tiny-sdfパッケージは、単一チャネル距離フィールドを生成します。 小さいフォントサイズでテキストをキャッシュする場合、シャープなコーナーは生成されません。 これは、レンダリングされる同じフォントサイズでキャッシュすることで軽減できます。

シングルチャネルSDFの生成はそれほど悪くないはずです。 マルチチャネルSDFは、複雑すぎることを除けば優れています。 Chumsklyがどのようにコーナーをエンコードしているか理解できませんでした。

現在、私たちが検討しているものはすべて、rtlとLtrの混合レイアウトをサポートしていません（ @eXponentaが正しく指摘しているように）。 でも、今は正式にサポートしているとは思いません。

正確なアプローチには2つの利点があります。キャッシュサイズが小さい（すべてのピクセルではなく頂点をキャッシュしている）、「アンチエイリアス」設定がオフになっている場合でもアンチエイリアス（テキストは常にアンチエイリアスされると予想されます。現在の実装ではキャンバスを使用してこれを行っています。 2D）。

デモについては、私の二次ベジェ曲線のデモを見ましたか？ https://codepen.io/sukantpal/pen/GRJawBg?editors=0010

-
私と@bigtimebuddyが最も簡単な解決策として話し合ったもう1つのことは、キャンバス2Dを使い続け、グリフをテクスチャにキャッシュすることでした。 グリフはクワッドとしてレンダリングできます。 キャッシュアトラスは、テキスト間で再利用できます。 もちろん、これは大きなテキストが同じサイズでキャッシュされていることを意味します。したがって、大量のテキストがレンダリングされているが、その一部（PDFの現在のページなど）のみが表示されている場合は、メモリ使用量が大きくなります。

良い、

はい、現在の方法で常に利用可能であり、すべてのカスタムテキストレンダリング技術が後日解決する必要がある問題であるrtlまたはltrについての心配はありません。
これらの決定。 理想的には、メモリ消費と実行時のパフォーマンスに焦点を当てる必要があります。

ベジェデモはかっこいいですが、全文をレンダリングした場合に隠れている可能性のある真の複雑さを理解するには十分ではないと思います。

上記の動的ビットマップフォントについて私が書いたものは、グリフキャッシングについてあなたが言ったこととほぼ同じです。 それは間違いなく降りるのに便利なルートだと思います！

要約すれば：

ベジェ曲線ソリューション：これは良いルートかもしれませんが、実際の本番ユースケースにどのように適合するかを理解するには、さらに研究開発が必要だと思います。

通常のフォントからの動的ビットマップフォント：これは、APIをシンプルに保ちながら、優れたパフォーマンスを提供することがわかっているため、確実に調査する必要があります。 私のお気に入り：D

シングルチャネルSDFマルチチャネルSDFほど優れていないことを理解していますが、デモは私にはかなり良さそうに見えました。 テキストが適切に拡大縮小でき、フォントごとに1つのテクスチャを使用できる場合は、このルートも調査する価値があると思います。

@GoodBoyDigitalデモにはかなり良いテキストがあると思います。 しかし、詳細を探そうとすると、目に見える違いがあります。

上部のテキストはシャープではありません-エッジに揺れがあります。 各フォント+（フォントサイズの約12〜15ピクセルの違い）の組み合わせは、個別にキャッシュする必要がある場合があります。

それらの小刻みに動くことが重要でない場合、または複数のフォントサイズでキャッシュを使用できる場合は、SDFを使用してもまったく問題ありません。

最も簡単な解決策も私にとっては問題ありません💯tbh！

やあみんな。

私はPixiのすべてに精通していますが、バックエンドとしてPixiを使用するGDevelopのユーザーであり、GDevelopによるPixiJSの実装とテキストレンダリングのためにしばらくこれを掘り下げてきました。 私が取り組んでいるテキストがたくさんあるゲームにとって、それは実際に影響力があります。 （GDevelopに投稿した問題で私の研究/例を見ることができます：https：//github.com/4ian/GDevelop/issues/1449）

私が見つけたオプションの1つは、テキストのスケーリングの問題を完全に無視し、常にテキストのスケールを100％のままにして、代わりにテキストのフォントサイズをスケーリングすることで、それらを完全に排除することに焦点を当てていました。 これはフォントに依存せず、すべてのサイズで機能するようです。

これがPixiを使用して行われているコード例です： https ：
私はこのスレッドでそれを見つけました： https ：

誰かがGDevelopのPixiText拡張機能を変更できることを望んでいたので、実際にはこの問題に恵まれていますが、（私は素人なので）これがPixi自体のはるかに大きな問題であることに気づいていませんでした。

この方法に潜在的な問題があるかどうかはわかりませんが、sdf / msdf / etcのパフォーマンスの問題をすべて回避できるようです。

@ Silver-Streakテキストディスプレイオブジェクトに適用されたスケールでフォントサイズを大きくすることを意味する場合、パフォーマンスの観点からどのように優れているでしょうか。 SDFのものは、大きなフォントサイズで再レンダリングしないため、パフォーマンスに役立ちます。

@ Silver-Streakもちろん、あなたの提案は_品質_を改善しますが、それがどのようにパフォーマンスを改善するかはわかりません。

@ Silver-Streakもちろん、あなたの提案は_品質_を改善しますが、それがどのようにパフォーマンスを改善するかはわかりません。

誤解しない限り、フォントサイズを変更すると、オブジェクト全体をスケーリングしたり、別のレンダラーに読み込んだりするよりも少ないリソースを使用しませんか？ 繰り返しになりますが、Pixiのスケーリングが実際にどのように機能するかについては、私は非常に素人です。フォントをネイティブ解像度のままにして、テキストサイズを変更するだけで、スケーリングするよりも高速になることは理にかなっています。 それが正しくない場合は、気を散らすことをお詫びします。

@ Silver-StreakScalingは変換として実装されます。 変換行列があり、その行列のスケールを変更するのは簡単な操作です。

現在のところ、テキストはCanvas 2DAPIを使用してキャンバスにレンダリングされます。 次に、画面にコピーされます。 スケールを変更すると、キャンバス内のテキストがマップされている画面座標が変更されるだけです。

ああ、それは理にかなっています。 残念ながら、私の問題は、拡大縮小後にフォントのグラフィックレンダリングがぼやけてしまうことですが、パフォーマンスも向上すると思いました。

一般的なテキスト品質の問題を修正するために誰かがそれを実装することを楽しみにしていますが、パフォーマンスも改善したいと思っていることは完全に理解できます。

それを通して私と話してくれてありがとう。

@ Silver-Streak問題ありません。 ただし、品質優先のテキストを実装することは、WebGLでも難しいことではありません。 一部のアプリケーションは、独自にメッシュを作成してテキストを実装しています。 フォントファイルを解析し、頂点のリストを作成して、テッセレーションすることができます。 これらの頂点は、メッシュを介してレンダリングできます。

高スケールでは、これによりわずかな「エッジ」が発生する可能性があります。最終的には、テキストを三角形としてレンダリングするためです。 さらに高品質にするために、このスレッドで説明した「正確なベジェ曲線」シェーダーを使用できます。これにより、曲線が三角形ではなく曲線としてレンダリングされます。

テキストの品質についてサポートが必要な場合は、私がお手伝いします:)

@SukantPal私は間違いなくGDevelopの貢献者ではありません（私もそうなりたくありません。私は主にビジネスシステムアナリスト/ DevOpsであり、開発者ではありません😄）。私はそのプロジェクトが大好きで、コミュニティで活動しています。 。 また、コミュニティの他のメンバーが、スケーリングされたテキスト品質のソリューションを見たいと思っていることも知っています。

ただし、投稿の問題を確認したい場合は、Bountysourceにもその恩恵があり、すべての人に開放されています。 ただし、ここではこれ以上ヘッドスペースを取り上げたくありません。一般的に、Pixiの周りではるかに深い会話が行われていることは明らかであり、私の提案は思ったほど的確ではありませんでした。

@ Silver-Streakコロナシーズンでやるべきことは何もないので、見てみるかもしれません

これがクローズドスレッドであることは知っていますが、テキストレンダリングを改善するための最良の方法を誰もがまだ探していると確信しています。 私は誰かがPixiv5で動作するmsdf実装を持っていることに気づきました。 https://github.com/cjsjy123/pixi-msdf-text-v5考えた私は興味のある人にそれについて言及したいと思い

このスレッドは確実に再度開いて存続させる必要があります。または、これは最も検索されている問題の1つであるため、少なくとも頻繁に何らかの更新を行う必要があります。