私は、JMP が他のすべての GUI フレームワークと同じ方法で表示要素を処理することを提案しました。つまり、コンテンツが変更された場合、または特定の再描画 (または無効化) メソッドが呼び出されない限り、どの要素も再描画しないということです。
具体的には、ウィンドウがスクロールされるたびにフレームボックスがコンテンツを再描画しないようにする方法はありますか(これには、すべてのデータ ポイントの再描画と、添付されたスクリプトの再実行が含まれます)? 真剣に言えば、一度描画して、ボックスが変更されない限り (サイズ変更 / dt RowState の変更 / inval メソッド)、ビットマップ (またはピクセル マップ) を永続的に保持します。
これは、何千ものポイントや複雑なスクリプトが添付されたグラフをスクロールするときに、生産性を著しく低下させます。「何があろうと可能な限り再描画する」という現在の方法は、非常に不可解です。
ここに例があります。添付のスクリプトは単にログに出力するだけですが、グラフをスクロールすると、スクロールボックスが更新されるたびにスクリプトが常に実行されていることがわかります（<
New Window( "Test",
vlb = V List Box()
);
::global function = Function( {},
Print( 1 );
);
For( i = 1, i <= 20, i++,
vlb << Append(
Graph Box(
Frame Size( 200, 200 ),
X Scale( -100, 100 ),
Y Scale( -100, 100 ),
::global function
)
)
)ご返信ありがとうございます！（ここで長々と返答してしまい申し訳ありません）
私のグループでは、ウェーハ上の欠陥を調べています。25 枚のウェーハからなるエクスカーション中に FOUP 全体をスキャンすることがよくあります。これらはエクスカーションであるため、ウェーハごとに数万または数十万の欠陥が存在することがよくあります。私たちのワークフローの一部は、これらのウェーハをチェックすることです。
プロットに少しのカスタマイズだけを行うスクリプトを作成しました。つまり、Path() コマンド (SVG 文字列を使用) を使用して欠陥点の下にダイを描画し、未分類の欠陥を描画してから追加します。分類された欠陥を含むマーカー セグメントが最後になります (分類された欠陥が未分類の欠陥によって隠蔽されないようにするため)。
25 枚のウェーハの最初のレンダリングには数秒かかる場合があり、多くの場合、それらを一度にすべて表示できます (ウェーハマップごとの画面上のサイズが比較的小さい)。ただし、ユーザーがより大きなウェーハマップを必要とする場合は、リストをスクロールする必要があります。ウェハーマップのスクロールは何も変化していないので非常にスムーズであるはずですが、もちろん、フレームの更新ごとに数秒かかります。
私の解決策は、ウェーハマップを描画した後に画像を作成し、その画像のみを表示することでしたが、テーブルの状態が変化した場合などに画像を再描画するために多くのオーバーヘッドが発生します。また、この方法では、最初のレンダリングに使用しない場合に比べて約 3 倍の時間がかかります。
以前の仕事で GUI API を作成しましたが、デフォルトは常に遅延評価でした。確かに、標準 JPEG (片面あたり 2^16 ピクセル) より大きい画像形式を使用する必要はありませんでしたが、これらの最大サイズは日常的に処理されていました。 JPEG は問題なく、数 MB の RAM しか使用しません。
私が理想的だと思うのは、表示エンジンのビットマップの遅延評価を確実にするために、FrameBox に何らかのメッセージを与えることができ、巨大なビットマップ (またはピックスマップ) が原因で潜在的に存在する可能性のある RAM の問題が残されることです。ユーザーの裁量に委ねられます。
これが私が扱っている問題の良い例です: (ポイント数が多いため、ウエハマップ コードでこの <痛いほど遅い、GraphBox は 1 つだけです。10 ～ 20 人が表示されている状態でこれを行うことを想像してみてください。
私は 64G の RAM と優れた 4 コア CPU を搭載したかなりまともなデスクトップを使用しています。これはハードウェア レンダリングを備えた JMP16 (JMP14 にも同じ問題があります) で、私は 4K モニターを使用していますが、標準の HD モニターを使用しているユーザーも同じ問題を抱えています。
Names Default to Here( 1 );
table = New Table( "test table",
Add Rows( 150000 ),
<<NEW column=""></NEW>
要約する：
- 表示マネージャーのビットマップを遅延評価する方法を提供していただけますか?RowState がいつ変更されるかはすでにわかっており、必要に応じて手動で再描画するための <
- ホバーテキストの試みを無効にする方法を提供していただけますか?これは多くのサイクルを消費し、この状況ではまったく役に立ちません (または、ポイントの上にボックスを描画するため、少し有害ですらあります)。
そして、私はこれらの他の小さな問題に長い間不満を感じてきたので、他にもいくつかリクエストをさせてください (もちろん、皆さんがこれらの問題に取り組んでくれることを期待しているわけではありません。そうしていただければ幸いです)やったね:)
- JMP12 では、オブジェクトの順序は FrameBox -> Customize... に従いました。 (右クリックメニュー)。具体的には、行が選択されている場合、それらの選択されたポイントは、リスト内でその後にリストされている追加グラフィックス スクリプトによって上書きされる可能性があります。JMP14 以降 (私は JMP13 を使用したことがないので、それについて語ることはできません)、選択した点が他のすべてのものの上に描画されます。これは、何千ものポイントを処理し、トレンドラインやその他のオブジェクトが選択されている場合にポイントの上に表示できない場合に問題になります。
- これは、ユーザーが凡例でカテゴリを選択し、ポイントが選択されたときに実際に機能します。突然、ユーザーには線が見えなくなります。
- これを示すコードについては以下を参照してください
- また、GraphBox 上にグリッドを描画するとき (ウェハーマップ内にダイを表示するためにこれを行います)、グリッドはアンチエイリアス処理されません。画像をクリップボードにコピーすると、やはり画像にはアンチエイリアスが適用されません。JMP12 はアンチエイリアスを実行し、画像は次のようになります。多くのより良い！
- JMP12 と JMP14/16 のアンチエイリアシングの比較については、以下を参照してください。
他のすべての可能な要素の上にある選択された点に関する問題の例:
Names Default to Here( 1 );
table = New Table( "test table",
Add Rows( 150000 ),
<<NEW column=""></NEW>
問題の画像:
線はデータ ポイントの上に描画する必要があります。
JMP12 は正しい順序で描画します。
アンチエイリアシングの例: (これらは私の主張を示す偽のウェハーマップであることに注意してください)
JMP14/16: プリントスクリーン:
JMP14/16 コピー画像:
JMP12 プリントスクリーン:
JMP12 コピーピクチャ:
ありがとう！！
やあ@Erratic Attack -
ご提案ありがとうございます。JMP にとってパフォーマンスは間違いなく重要です。一部のレポートは高さが 100k ピクセルを超える場合があるため、JMP はスクロール領域に現在表示されているコンテンツのみを描画します。Windows では、可能な限りピクセルをコピーし、「新しい」コンテンツのみを再描画するために、小さなスクロール値に合わせてスクロールが最適化されています。
あなたのユースケースについてもう少し詳しく教えていただけますか?特に：
- Mac または Windows
- ウィンドウの大部分はプラットフォームまたはカスタム グラフで構成されていますか?
- グラフィックス スクリプトは大量の描画を行っていますか、それとも他のタスクに使用されていますか?
JSL を使用して大量のジオメトリを描画している場合は、JSL ではなく表示セグメント (マーカー セグメント、ライン セグメント) を使用することで高速化できる場合があります。
