Pixi.js: コンテナに固定境界を設定するオプションを提供する

コンテナには領域と固定境界がなく、単なる子のコレクションであり、これがデフォルトのPIXIの動作です。 境界を修正したい場合は、独自のコンテナを拡張し、「calculateBounds」メソッドをオーバーライドします。

領域と固定境界がなく、本質的に単なるデータ構造である場合、レンダリングに影響を与えることはありません（iframeに大きすぎるオブジェクトを配置した場合と同様に、iframeは大きくなりません）。 。 例ではそれは明らかにそうです、そして私は例の不完全な論理でそれを非難するのが難しいと思います。 固定境界オプションがないことは問題の根本を調べていないかもしれませんが、問題は間違いなくそこにあります。

「オフスクリーン」要素を実装することをどのように提案しますか？

とにかく境界が必要なのはなぜですか？

例を見たことがありますか？ 奇妙な振る舞いは、 drawDebugLinesが実行され、「アイコン」コンテナに線を引くたびに、そのコンテナが大きくなるという事実によって引き起こされます。 スナップポイントはコンテナの寸法（幅/列、高さ/行）に依存するため、スナップポイントが台無しになります。

スナップをレンダリング要素にマップすると、2つの問題が発生します。レンダラーは、画面サイズ、向き、ピクセル密度、および描画要素のユーザー指定の寸法に依存します。 大きいアイテム（画面外、スライドできるなど）と小さいアイテム（デスクトップ1とデスクトップ2を同時に表示する場合など）の両方を含めることができます。これらすべての場合で、スナップやその他の制約を維持する必要があります。 。

lel.width = wonderfulRectangle.width * 0.8;
lel.height = wonderfulRectangle.height * 0.9;

なぜ定数として使用しないのですか？ 次のようなグローバルなものをセットアップできますか？

var globalRect = new PIXI.Rectangle(0, 0, renderr.width/renderer.resolution, renderer.height/renderer.resolution);

サイズ変更のたびにそのrectを更新し、それを操作します。 なぜ「lel.width」と「lel.height」が必要なのですか？

LEL。 それは何の関係もありません。移動できるのはスプライトだけです。元の画像が大きすぎて長方形に収める必要があるため、幅と高さを設定しています。 のコードを見ると、その「アイコン」のメインコンテナがdesktop1であり、アイコンをスナップしようとしているコンテナであることがわかります。 それはdesktopLayerに属し、desktopLayerは私がステージに置いたものです。

私がエミュレートしようとしているのは、複数のスワイプ可能なビューとデスクトップの背景上のアイコングリッドを備えたAndroidランチャー画面の動作です。

return new PIXI.Point(snapPosX.clamp(0, target.parent.width), snapPosY.clamp(0, target.parent.height));

私はまだあなたが何を望んでいるのか理解していません。 PIXIコンテナの境界は、想定どおりに機能します。 この間違いを犯したのはあなたが最初ではありません。

ああメーカーの息、私はもうこれを行うことはできません。 誰かが例を見て、怒りの顔を動かして、なぜその線のがらくたが起こっているのか、それがPIXIのバグ/欠落機能なのか、それともコードに間違いがあるのか​​を教えてもらえますか？

これは、線が実際にコンテナの幅と高さに影響を与え、そもそもそれらのプロパティを使用して線を描画するためだと思いました。

また、codepenはどういうわけかもう私のために働いていません。 なぜ何かアイデアはありますか？

ええ、それは私にとっても壊れていました。なぜなら、私が誤ってinitコールをコメントアウトしたからです。 はい、あなたは正しいです-それは私がしていることであり、グリッドを視覚的に反映するためにそれらの線を描く他の方法はありません。 では、これらの線を引くために、正確に何を提案しますか？ 関連するレンダリングされたコンテナの寸法を常にコピーする、ある種の個別のメタのみのRectangleオブジェクトを設定し、それを使用してスナップポイントやその他の位置を導き出しますか？ それは、問題を解決するのではなく、問題を回避するための過剰設計のようです。 コンテナが通常のDOM要素のように「オーバーフロー」を起こせない理由はありますか？

私はこれを問題として投稿しました。解決策がないからではなく、この非論理的な振る舞いの正当性がわからないからです。 特に、線は実際にはコンテナの境界の外側に出ていないため、端から端まで描画されます。 私が構築している製品では、ユーザーがコンテンツと多くの対話を行うことが期待されています。シーン内のすべてのオブジェクトに「参照長方形」を設定する必要がある場合、コードが非常に乱雑になり、保守が困難になるのではないかと心配しています。 。

あなたは私が私のコードに「間違い」を持っていると言いました。 その間違いは何ですか？ 私は非常に徹底的に検索しましたが、欠陥のあるロジックは見つかりませんでした。

変化する「幅/高さ」の代わりに、いくつかのグローバル変数を使用してください。 必要に応じてその変数を更新します。

var globalRect = new PIXI.Rectangle(0, 0, renderer.width/renderer.resolution, renderer.height/renderer.resolution);

「ローカル」境界が必要な場合は、それらを作成しますが、pixiと同じ変数を使用しないでください。

container.myRect = new PIXI.Rectangle(0, 0, renderer.width/renderer.resolution, renderer.height/renderer.resolution);

間違いは、PIXIにはレイアウトがまったくないということです。 「幅」と「高さ」の意味は異なります。 子が影響を与えるため、親の幅の高さで子座標をクランプすることはできません。

グラフィックスの境界全体ではなく（円もある場合はどうなりますか？）、子の境界ではなく、グラフィックス内に描画した長方形の幅/高さが必要であることをPIXIが知る方法はありません。 境界の唯一の合理的なロジックは、境界内のすべてを取り込むことです。

2つのスプライトを持つコンテナがあり、それぞれに（w = 10、h = 10）があり、1つは（0,0）にあり、もう1つは（100000、100000）にあると想像してください。 そのコンテナの幅と高さはどれくらいですか？ また、どういうわけか境界を修正しても、それらは何に影響しますか？

そして、どういうわけか幅と高さを変更したい場合、その変更はコンテナ内の要素にどのように影響しますか？

私は冗談ではありません。他のAPIのデザインを想像するのは本当に難しいです。 レイアウトの追加コンポーネントとなる可能性のあるアイデアがある場合は、ここに書き込んでください。 GUIではなくステージレンダリングを扱っていることを覚えておいてください。パフォーマンスが実際の問題です。

ねえ@megakoresh 、私はここで混乱を引き起こしているものを知っていると思います。 pixiの主な目的は2Dオブジェクトをレンダリングすることであるため、ほとんどすべてのAPIはその目的に向けられています。 境界は特に混乱を招く可能性があります。

pixiでは、スプライトの境界はテクスチャによって定義されます。 つまり、レンダリングされたオブジェクトの最終結果のサイズです。 同様に、コンテナは_描画されない_ため、コンテナの境界はコンテナに含まれる子によって定義されます。 特に、それらの子供たちの境界によって。 Graphicsオブジェクトの場合、境界は、オブジェクトに描画するジオメトリによって定義されます。 現在の境界の外側にあるGraphicsオブジェクトに別の長方形を描画すると、境界が拡張され、新しく描画されたジオメトリが含まれます。

うまくいけば、それは理にかなっており、Pixiで境界がどのように構造化されているかについての簡単な概念を提供します。

さて、特にあなたの例では、あなたの問題は、グラフィックスオブジェクトの境界がどのように機能するかについての誤解から来ていると思います。 グリッドを描画すると、緑色の四角形（ wonderfulRectangle ）を含むGraphicsオブジェクト（ desktop1 ）の境界が変更されることを見逃していると思います。

最初の描画後、グリッドがビューポートのサイズから外れていることがわかります。

これにより、親Graphicsオブジェクト（ desktop1 ）の境界が拡張され、ビューポート外のジオメトリが含まれます。 これにより幅が大きくなり、グリッドの次の計算が中断され、サイクルが続行されます。 線には太さがあり、幅を占めることを忘れないでください。

これを修正する方法はいくつかありますが、頭に浮かぶのは、グリッドがビューポートのサイズ全体を占めるため、親のサイズではなくビューポートのサイズを使用することです。 これは、ビューポートの外側にさらにジオメトリを描画した場合、グリッドの計算が変更されないことを意味します。 レンダリングビューポートはサイズを変更しないためです。

それがオプションでない場合、たとえば、グリッド領域はビューポートのサイズではありません。 グリッド領域の「既知のサイズ」に基づいて計算を行うことができます。 それが、静的なRectangleインスタンスの使用についてIvanが言おうとしていたことだと思います。 基本的に、グリッドが800x600であると判断し、それに基づいて計算を実行し、シーン内のオブジェクトの実際にレンダリングされた境界を実行しました。

説明したビューポートメソッドを使用するようにコードペンを更新しました。 他にご不明な点がありましたらお知らせください。

http://codepen.io/anon/pen/yarVwm?editors=0010

笑k。 ですから、皆さんの力を合わせて、問題の核心を理解していると思います。ライブラリがキャンバスライブラリと組み合わされることが多い場合、それは同じものであると思いましたが、明らかにそうではありません。 ビジュアルオブジェクトのグループ化やオーバーフローなどの処理はスコープ内ではなく単純であり（ライブラリをさらに学習すると、そのプラグインを作成できるようになるかもしれません）、PIXI自体が処理する一方で、自分で処理する必要があると思います。画面に物を表示するだけです。 ケースは閉じました、ありがとう。

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