Pixi.js: gl-matrixと見なされますか？

1）SIMDは死んでいます。 https://github.com/rwaldron/tc39-notes/blob/a66df6740eec3358d5e24f81817db99d6ee41401/es8/2017-03/mar-21.md#10if -simdjs-status-update

2）単純な6つのフィールド「a、b、c、d、tx、ty」は、Float32Array（9）行列よりもはるかに優れたパフォーマンスを発揮します。 カントはテストへのリンクを提供しますが、私と@GoodBoyDigitalの両方がすでにそれを統合しようとしました。

3）JSは倍精度を実行します。これは、大きな座標で動作するアプリにとって重要です。 グラフィックスとスプライトの「プロジェクションxトランスフォーム」は、JS側に配置することをお勧めします。

私はv5でFloat32Array（9）を使用しています。これは、jsperfテストでは、同じパフォーマンスではないにしても類似しており、toArrayや転置操作を行う必要がありません。

https://github.com/pixijs/pixi.js/blob/455c059e8d155c1d9a05fc2ece2c02b3bdf8bf84/plugins/core/src/math/Matrix.js

gl-matrixはSIMD（Ivanが述べたようにデッドスペックです）を持っていたので有益ですが、それらの実装にも欠点があります。 3x3行列（ Float32Array(9) ）をGPUにヒットさせたいのですが、計算時間を節約するために、2D行列であるかのように操作を実行します。 gl-matrixは、そのための適切なメカニズムがありません。

v5バージョンは、GPUに直接アップロードできるストレージを使用するだけでなく、関心のある2Dパーツでのみ動作します。 また、SharedArrayBuffersやその他の最適化を使用できるように設定されているため、Webワーカーにより多くの作業を行うことができます。 それでどこまで到達できるかを見ていきます。

@englercj一貫性を保つために、多くの場所でMath.froundを使用する必要があるのではないかと思います。 perfFloat64Arrayを試してください。

Float64Arrayにすることもできますが、アップロードするには単精度にダウンサイズする必要があります。 GPUにアップロードするときは、現在float32を使用していることにも注意してください。 したがって、計算を2回実行してから、1回に切り捨てます。 これは、すべてを1つで行うよりも正確かもしれませんが、アップロードするデータ型と一貫性を保つように努めたいと思います。 残念ながら、これはGL 4.0までは単精度を意味し、WebGL2はGLES3.0のみです:(

マトリックスのアップロードがボトルネックになることはありませんでした。これらの場所では「uniform3fv」を使用します。これは簡単な操作ではなく、その後にdrawCallが続き、ほとんどの場合、大きなバッファーのアップロードが続きます。 重いpixiアプリは、フレームごとに約400回のドローコールしか実行していません。

大きな座標でユーザーの問題に遭遇した後、アップロードするまですべてを倍精度で保存することを好みます。

また、「a、b、c、d、tx、ty」表記は、「0,1,3,4,6,7」よりも書き込みと読み取りが簡単です。 脊椎でも使用され、その上に非常に洗練された変換があります。 マトリックスに切り替えると、後でコードをチェックするのはそれほど簡単ではありません。 行列演算を想像するのが難しい人もいますが、私はそれらを簡単に読みます。

UPD。 また、これは行列の変換以上に役立つと思います： https ：

UPD2。 しかし、3D変換の場合、Float32Array（16）の方が優れているので、反対するつもりはありません。

私の投票は、最高のパフォーマンスを提供するものに行きます。 最後に、配列上のオブジェクトを使用してチェックした方が高速でした。 それがまだ本当かどうかは100％わかりませんが、それはおそらく変わったかもしれません！

3Dの場合、主にGPUに大量にアップロードされるため、gl-matrixスタイルが好きです。 Pixiでは、これは一般的には当てはまりません。 ほとんどの操作はjsランドで行われます（例：スプライトバッチャー）。

https://jsperf.com/obj-vs-array-view-access/1

これが私が行ったテストです。 オブジェクトは、方法遅い通常の配列よりもどちらも、Float32Arrayよりも遅いですuniform3fvは通常のArrayオブジェクトを受け入れるので、それに切り替える必要があります。

編集： Array結果はまぐれだったようですが、再現できませんか？

私の投票は、最高のパフォーマンスを提供するものに行きます。
最後に、配列上のオブジェクトを使用してチェックした方が高速でした。

それはとても興味深いです。 基になるvmは、オブジェクトのセマンティクスが大幅に削除される可能性があることを知っているため、多くの最適化を実行できるはずなので、オブジェクトが純粋な数値配列よりも高速であるというのは直感に反しているようです。 _なぜ_オブジェクトの方が速いのか、何かアイデアがあれば知りたいのですが。

私のコンプ（i7、Windows 10）からの関連する結果：

Chrome 59：

Firefox 54.0.1（32ビット）：

Microsoft Edge 40.15063.0.0：

Array方が速いという私のクロムの結果はまぐれだったようです。それが何であったかはわかりませんが、今は再現できません。 約5,000万ops / sですが、以前に行った1回の実行では5億ops / sでした。 変...

いずれにせよ、Float32Arrayメンバーは、すべてのブラウザーでオブジェクトと同じ速度またはオブジェクトよりも一貫して高速です。 それが私がそれを切り替えた理由です、それは以前と同じ速度（またはより速い）ですが、今ではアップロードのために配列を転置して埋めることを避けています。

Float64でも同じことができますか？ :)

私は、drawcallごとに約1つ以上の行列演算よりもコード品質に関心があります。

また、反転はあまり使用しません。 updateTransform（）が問題です。

私は、drawcallごとに約1つ以上の行列演算よりもコード品質に関心があります。

Float64Arrayのコード品質はどのように高くなっていますか？ 精度が上がることは理解していますが、とにかく単精度に減らすことを考えると、なぜそれがそれほど重要なのかを理解できません。

また、反転はあまり使用しません。 updateTransform（）が問題です。

これは、データストレージの読み取り/書き込みのベンチマークであり、その間の値に対して実行される操作は無関係です。

私は、drawcallごとに約1つ以上の行列演算よりもコード品質に関心があります。

私もこれに同意します。 配列ベースの行列、点、ベクトルの「標準化」は、実際にはパフォーマンスよりもコード品質の向上につながる可能性があることを考慮してください...人気のあるjs行列/ベクトルライブラリの再利用と、人気のあるレンダリングモジュールとの相互運用性の向上を検討します大きなコード品質の勝利になるために。

これは、データストレージの読み取り/書き込みのベンチマークです。
関係のない中間の値に対して実行される操作。

私はあなたが両方とも正しいと思います。 これは、データストレージの読み取り/書き込みの一般的なベンチマークです。 しかし、Ivanには本当に良い点があります。 updateTransform()が圧倒的な操作である場合、それを確認することは説得力があります。

私は一般的にマイクロベンチマークについて心配しています。 これらの静的データセットを使用すると、これらのテストでjavascriptvmsのコンパイラ最適化を誤って利用してしまうのではないかと思います。 実際のテストを実行することは、はるかに啓発的です（セットアップにはるかに多くの作業が必要になるという犠牲を払って）。

私もこれに同意します。 配列ベースの行列、点、ベクトルの「標準化」は、実際にはパフォーマンスよりもコード品質の向上につながる可能性があることを考慮してください...人気のあるjs行列/ベクトルライブラリの再利用と、人気のあるレンダリングモジュールとの相互運用性の向上を検討します大きなコード品質の勝利になるために。

私は "（a、b）、（c、d）、（tx、ty）"倍精度行列を使用しており、アップロード用にfloat32arrayに変換され、 "posX、posY、pivotX、pivotY、scaleX、scaleY、 ShearX、shearY、rotZ "。 とにかくフォークで使用しますが、マスターpixiでも行列配列を扱いたくないです。 それが私の標準です。

また、jsのvec数学に1つまたは2つの標準を使用させることが可能かどうかも疑問です。

Float64Arrayのコード品質はどのように高くなっていますか？ 精度が上がることは理解していますが、とにかく単精度に減らすことを考えると、なぜそれがそれほど重要なのかを理解できません。

updateTransformでは、カメラ変換にスプライト変換（スクロール用）を掛けます。 結果は小さい場合にのみ画面に収まるため、最終的には数値は小さくなりますが、スプライトの位置とカメラの位置の両方が大きくなる可能性があります。 ユーザー側のソリューション：

1）彼の側ですべてを計算します。 PIXIは比較的小さな座標のみを扱います。
2）世界を大きな座標を持つチャンクに分割します。スプライトには比較的小さな座標がありますが、サブピクセルカメラでは機能しません=>カメラには大きな座標と小さな座標も必要です。

大きなプロジェクトの場合はユーザーに自分の側でそれを強制することは問題ありませんが、小さなプロジェクトの場合はもう1つ頭痛がします。

また、jsのvec数学に1つまたは2つの標準を使用させることが可能かどうかも疑問です。

意味がわかりませんが、詳しく教えていただけますか？

意味がわかりませんが、詳しく教えていただけますか？

私にはできません、それは私には多すぎます。

低レベルの最適化の両方で異なる経験を持つ人々がいます。 および言語構造、DSL-s。 あるレベルで私たち全員を満足させる標準が必要です。

過去2年間で、異なる変換を使用してpixiの2つのフォーク（v3とv4用）を作成しました。独自の高度な変換を備えた「pixi-spine」を扱っており、3番目のフォークを作成しています。 「過去のivan」の観点からは、配列は最も単純な形式であり、「gl-matrix」があるため、最適です。

64ビットを維持することが重要であるという@ivanpopelyshevに同意します。 フレームごとにバッファを作成およびコピーせずに、これを効率的に行う方法を理解しようとしています。

たぶんそれをFloat64Arrayとして保存し、アップロードするときにFloat32Arrayにコピーします。 これにより、少なくとも、型付き配列をストレージバッキングとして使用できるようになります。これにより、Webworkerとの間で簡単にコピーできるようになります。

Float64Arrayは、（0,1）、（3,4）、（6,7）をX、Y、translateとして使用することを覚えておく必要があります。

すべての興味深いスタッフ、私は私たちが提案したソリューションを実際のpixiシナリオ（バニーマークのようなもの）でベンチマークすることを切望しています。

この分野での私の経験では、私と@ivanpopelyshevが最後にバニーマークのgl-matrixに切り替えたとき、実行速度が大幅に遅くなっていることがわかりました（3分の1遅いように！）

それは少し前のことでしたが、私はここで間違っていることを本当に望んでいます！
速度差が無視できるようになった場合、上記の提案されたルートはエースになると思います。

Pixiは高速です：Pソリューションに完全にコミットする前に、テストを確認しましょう。

Float64Arrayのベンチマークはまだ必要です。 この実装は私には受け入れられますが、個人的にはフォークで古いマトリックスを使用します。 また、互換性のためだけにプロパティを追加することを忘れないでください。

もう一つは：@mreinstein、私は覚えていないstandartsの一つはPaperScript、paper.jsのためにその言語の特別で、言語に直接小数点演算を追加します。 JSにシンタックスシュガーがもっとある場合は、そのようなものも使用します。

re：この更新されたバニーマークについて私が手助けできることはありますか？ これで時間を寄付できてうれしいです。

ここで起こっているパフォーマンスと一緒にフォローすることに非常に興味があります。 結果に関係なく。 配列ベースのものがまだかなり遅いことになった場合、私はその背後にある_理由_について本当に興味があります。

注意すべき点：パフォーマンステスト... chromeのv8は最近（v59で）ターボファンと呼ばれるv8へのかなり劇的な変更をリリースしました。 おそらく、パフォーマンスが大幅に向上しています。

https://v8project.blogspot.com/2017/05/launching-ignition-and-turbofan.html

ターボファンが存在する前のバージョンと現在のバージョンで更新されたバニーマークを実行するのは興味深いかもしれません。

@GoodBoyDigitalベンチを更新して

https://jsperf.com/obj-vs-array-view-access/1

エッジ上でのみ、オブジェクトの速度はFloat64Arrayと一致/超過し、実際に接近しています。

私は自分の環境でこれをテストしましたが、同様の結果が得られました...一体何ですか？！ Float64配列の読み取り/書き込みが同等のFloat32配列操作よりも大幅に高速なのはなぜですか？ 頭に浮かぶ唯一のことは、64ビットのフロートが単語の境界に整列することです。 私は当惑しています。

@mreinsteinのオファーを

最良の方法は、 pixiをフォークしてから、変換をgl-matrixまたは

次に、微調整されたバージョンができたら、ここでパフォーマンスをテストできます： https ：
さまざまな配列タイプをいじることができます。

@englercjそれは素晴らしい男です！ これらの結果を確実に見ることは励みになります。 v5バージョンはバニーマークを回転させることができる状態に近いですか？

@mreinsteinはただの予感です、64ビット-> 32ビットからの変換に関係しているのではないかと思います
jsの数値は64​​ビットですよね？

@GoodBoyDigital多分あなたが正しいと思います。 私の友人夫人に頼る。 グーグル、私はこれに出くわしました：

https://stackoverflow.com/questions/15823021/when-to-use-float32array-instead-of-array-in-javascript

最高評価の回答（現在44票）は合理的で関連性があるようです。

あなたがいくつかのパフォーマンステストで私たちを助けることができれば

了解しました。喜んでお手伝いさせていただきます。 :)

最善の方法はフォークピクシです

@GoodBoyDigital @englercjこの時点でフォークするのに最適なブランチは何ですか？

次に、変換をgl-matrixまたは@englercj行列クラスに置き換えます。
この場合、エンジン全体ではなく、スプライトバッチも機能させる必要があります。

これについてもう少し詳しく説明していただけますか？ パフォーマンスベンチを実行するためだけにエンジン全体をgl-matrixに変換したくありません... https：//github.com/pixijs/bunny-markにスプライトバッチのものがありませんバニーが追加されるルート要素としてのPIXI.Container。 pixi.container、pixi.spriteから始めて、そこから依存関係ツリーを逆方向に移動して、変換要素を置き換える必要があるすべての場所を見つける必要があると言っていますか？ 同意しないと言っているのではなく、不要な作業を最小限に抑えるための戦略が正しいことを確認したいだけです。

updateTransformには、次の2つの行列演算があります。

1. 位置、ピボット、スケール、回転からの構成-改善することはできません。
2. 親行列による乗算-改善することができます。

Float64Arrayに裏打ちされた古い「a、b、c、d、tx、ty」プロップで行列クラスを作成し、updateTransformを書き直すことをお勧めします。 また、 @ mreinsteinはコアになるのに十分なものを作成しました。彼を追加することをお勧めします。そうすれば、彼はブランチにアクセスしてファームを構築できます。

だから彼は枝にアクセスして農場を建てることができます。

誰もがそれにアクセスでき、fork + PRがすべてを行います。

バニーマークでどのような結果が得られるのか興味があります。デフォルトの100kバニーでChromeからさまざまなブランチ（開発、リリース、その他）を試してみると、一貫して10〜16fpsが得られます。 8.75秒を超えて実行されているコードでパフォーマンス分析を実行する：

ほとんどすべての時間はjavascriptの呼び出しに費やされます。

javascriptに費やされたこの時間のうち、時間の大部分は実際にはSprite.calculateVertices()に費やされています。 TransformStatic.updateTransform()費やされるよりも4倍多い

Firefoxでは、フレームレートが約2倍になりますが、費やした時間の内訳は似ています。 calculateVertices()は、両方のブラウザで大部分の時間を占めます。 これは予想されますか？ バニーマークの実行でも同様の結果が得られていますか？

これはバニーに期待されています。 そして、私たちが話している行列演算は、乗算用のupateTransform（）とcALLごとに1回のflush（）の2つの場所で実行されます。 大規模では問題ありません。

よくわかりません。 :(そのベンチマークのパフォーマンスをどのように知ることができますか？それは主に達成された純粋なfpsに基づいているという印象を受けました。それが本当なら、私のフレームレートは頂点の計算によって_厳しく_抑制されています。貼り付けた最初の図を見てください。上記では、レンダリングは合計フレーム時間のごく一部です。頂点と変換の更新は合計フレーム時間を圧倒しています。

それが誤りであり、fpsが私のpixiビルドのパフォーマンスの測定値ではない場合、特定のビルドを測定するためにどのような基準を使用しますか？

CPUまたはGPU側のいずれかでスロットルできます（図には示されていません）。

FPSが60をはるかに下回っているが、「アイドル」が大きい場合、つまりGPUです。

アイドル状態が小さい場合は、そのCPU。

computeVerticesには、内部に行列演算があります。4つのコーナーに行列を乗算するだけです。

TSフォークのほんの小さなアイデア：行列タイプのプロパティをインライン化する変換を追加します。 TSにはまだそのような変換がないのは残念です:(

行列変数に注釈を付ける方法を見つければ、babelでも実行できると思います。

もう何が起こっているのか理解できません。

覚えておくべきこと：そもそもこのベンチマークの目標は、オブジェクトとgl-matrixの使用が、予想どおり、パフォーマンスに大きな打撃を与えるかどうかを確認することでした。 ベンチマーク結果の違いに関係なく、オブジェクトのパフォーマンスはほとんどの配列の場合よりも悪くないことを一貫して示しているようです。

また、バニーマークのプロファイルを作成したので、ここでは一般的なpixiに関するパフォーマンスの結論を引き出すことは避けたいと思います。 Chromeでは、プログラムの合計時間の50％以上がSprite.calculateVertices() （40％ish）に費やされ、続いてTransformStatic.updateTransform() （11％ish）Firefoxの実行速度は2倍になりますが、その比率はこれらの2つの機能に費やされた時間の割合は依然として一貫しています。

トピックから離れすぎないようにしたいのですが、このバニーマークプロファイリングを行う際に、es5ゲッター/セッターの使用がクロムのパフォーマンス低下と関係があるのではないかと考え始めています： https： //jsperf.com/es5-getters-setters-versus-getter-setter-methods/10

ここでたるみにぶらぶらしている人はいますか？ ここでメッセージを渡すよりも、半リアルタイムでチャットする方が簡単だと思います。

@mreinsteinに何をメールしますか？ たるみにあなたを招待します👍

@englercjの発言に基づくと、明らかにこれは行っていません。 閉鎖。

ほんの小さな更新：Float64Arrayに基づいて、 https：//github.com/pixijs/pixi-projection/blob/master/src/Matrix2d.tsに3x2ではなく3x3マトリックスがあり

このスレッドは、閉じられた後に最近のアクティビティがないため、自動的にロックされています。 関連するバグについては、新しい問題を開いてください。