要件がまだわからない場合、描画システムを選択するにはどうすればよいですか？
2Dデータの処理と表示のためのアプリケーションを開発しています。現時点では、データは強度に応じて各ポイントを色に変換することで表示されるため、かなり低レベルのコードで表示されます。これはうまく機能します。新しい機能は、その画像上でマウスを使用して移動できるグリッドと一連の線を表示することです。
いつものように、新しいテクノロジーを選択するときは、いくつかのことをテストするために小さなデモを作成しました。現在のデータプロットを使用して、マウスで上下に移動できる線を上に描画し、同時にカーソル座標を表示するテキストがあります。私はいくつかの異なる方法を試しました：Canvasを使用する、somehwatの低レベルのDrawingContextを使用する、そして低レベルのWriteableBitmapExapiを使用する。
私にとって、コーディングのしやすさや表示速度に実質的な違いはありませんでした。はい、Canvasオプションのコードは他のオプションよりも数行少なくなっていますが、低レベルのオプションの方が表示がやや速いという印象を受けました。しかし、大きな違いはなく、すぐに選ぶことができます。
したがって、問題は次のとおりです。仕事に最適なシステムを選択する方法がわかりませんが、アプリのグラフィック部分は今後も拡大する可能性があるため、決定することは非常に重要です。言うまでもなく、今Aを選ぶと小さな災害になり、1年後にはBの方がはるかに良かったと思います。通常、私は最速または最も便利なオプションを選択するか、将来の要件を調べて、最適と思われるシステムを使用しますが、この場合、単に十分な違いはなく、将来の要件は正確にはわかりません。線、円、テキストを描画できれば十分であり、更新速度はそれほど重要ではありません。ただし、アプリケーションは初期段階にあり、基盤となるハードウェアも初期段階にあり、顧客数は100人未満です。ただし、それは急速に変化する可能性があります。そして、要件もそうです。
質問は簡単です：何をすべきか？私が考えてきたいくつかのオプション：
- '最も感じる'ものを選択してください（WriteableBitmapExですが、おそらく私が低レベルのものと親和性があるという理由だけで）
- コードの量が最も少ないものを選択してください（Canvasは、エフェクトやマウスイベントなどを使用してUIレベルでも非常に簡単に見えます）
- より広範なデモを作成して、違いがより明確になるようにしますが、すべてをインターフェイスの背後に配置して、実装を後で交換できるようにします（かなりの作業になる可能性があります）
いずれにせよ、より高いレベルのコードが必要になります。問題は、誰がそれを書くのに適しているかということです。その地域でほとんど経験のない人、または何千人もの人々が使用する生計を立てている執筆ライブラリを作っている人ですか？私はここで意地悪をしようとはしていませんが、彼らはあなたがまだ存在していることにさえ気づいていない何十もの問題をすでに解決しています。資格があり、それらを置き換える正当な理由があるまで、より高いレベルのAPIを使用してください。
また、私の経験では、最悪のボトルネックは、私がたまたま選択したサードパーティのライブラリではなく、自分のコードにある傾向があります。データを絶えず再計算するのではなく、データをキャッシュしておくなどのことに焦点を当てます。ディスクアクセスを避けてください。 GUIコードは、システムの他の部分から可能な限り切り離してください。描画コードがその仕事をするために知っておく必要のある最低限のことを考え、明確に定義されたインターフェースを使用してそれを提供します。
まともな分離設計では、将来的にもっと効率的なものが必要であることに気づき、新しいレンダリングメカニズムを実装することは、見た目ほどの作業ではありません。
私のアドバイスは、あなたとあなたのチームが最も快適なコンポーネントを選択することです（それが最も簡単であるか、過去に使用したものに最も近いものであるかどうか）。次に、最大の関心事は、モデル/ロジックをレンダリングから可能な限り切り離して、必要に応じて同じインターフェイス上に新しいレンダリングシステムを再実装できるようにすることです。
要件がよくわかっておらず、使用できる本格的なシステムがないため、最適化を実行できる時点ではありません。そのため、現在実行されている最適化は時間の無駄になる可能性があります。
より広範なデモを作成して、違いがより明確になるようにしますが、すべてをインターフェイスの背後に配置して、実装を後で交換できるようにします（かなりの作業になる可能性があります）
これが必要になります。
この「グラフィカル」UIコントロールには、次の要件があります。
- テキストとラベルの高速画像合成
- ダブルバッファリング（ちらつきを避けるため）
- マウスクリック座標をグラフィカルオブジェクトにマッピングする機能。
- 複数のグラフィカルオブジェクトが重なる状況には特に注意してください。この状況の処理が不十分だと、ほとんどの人がアプリケーションを使用できなくなります。
低レベルのオプションの方が表示がやや速いという印象を受けました。
あなたの考えに反して、一部の高レベルのフレームワークは、ピクセルのレンダリングと構成の重労働を低レベルのフレームワークに委任します（その後、ハードウェアに委任します）。したがって、パフォーマンスの違いは重要ではない場合があります。
主な質問は、どの合成アルゴリズムが使用されているか下選択するフレームワーク、およびそれが十分に高速であるかどうかです。
そのような構成戦略の2つの例を示します。
- キャンバスの上に描画されるテキストとラベルごとに、最初に個々のRGBA32透明レイヤーにレンダリングされます。これらのレイヤーはすべて、後で最終的なビットマップに合成されます。
- 描画されるテキストとラベルごとに、「宛先」ビットマップがロックされ、それらのピクセルが直接変更されます。 「インクピクセル」のみを変更する必要があります。
これらの戦略にはさまざまなトレードオフがあります。 （最初の戦略は並列化できますが、より多くのメモリ（RGBA32）とより多くの計算（構成）が必要です。2番目の戦略はシリアルですが、必要なメモリと計算は少なくなります。）また、一部の戦略は、他の戦略よりもGPUレンダリングに移植性があります。
私たちはコンピュータグラフィックスの専門家ではないので、わからないどの戦略が勝つかを予測するのに十分な知識があります。したがって、実験（広範なデモ）に頼って調べます。
まず、十分な情報がないため、現在適切なフレームワークを選択できないという事実に同意する必要があります。したがって、間違っていることが判明した場合に後悔を最小限に抑えるフレームワークを選択する必要があります。言い換えれば、最も柔軟なものを選択してください。
たとえば、悪夢のシナリオの1つは、低レベルのフレームワークを選択することです。そうすると、すべてのニーズがかなり標準的であることがわかります。低レベルのフレームワークでは冗長で面倒なメソッドの作成、デバッグ、および保守に多くの時間を費やしますが、高レベルのフレームワークにはすでに存在します。さて、高レベルのものでは、必要なときに低レベルのコードを書くこともできますか？それはより良い選択かもしれません。
つまり、高レベルのコードを作成するのか低レベルのコードを作成するのかわからない場合は、一方に最適化されているが他方に災害が発生するフレームワークではなく、両方に問題のないフレームワークを選択してください。 1年後、どのフレームワークを使用すべきかがわかりますが、これはこのフレームワークではありません。しかし、より柔軟なものは、最適よりも少しだけ悪くなります。パフォーマンスにも柔軟性が必要です。必要な場合に高速コードを記述できるものです。
もう1つできることは、描画コードを内部インターフェイスの背後に配置して、本当に必要な場合に後で交換できるようにすることです。これは思ったより難しいです。低レベルのフレームワークを選択すると、インターフェイスは低レベルの概念に引き寄せられます。そして-驚き！ -多くの場合、フレームワークの概念だけです。しかし、このルートに行く場合は、ユニットテストが必須です。まず、特定の機能だけを実行するテストを作成すると、コードの他の部分と絡み合わない方法でその機能を作成する必要があります。次に、後でバックエンドを交換する必要がある場合は、何が壊れているかを簡単に見つけることができます。
もう1つ注目すべきことは、どのフレームワークが最も勢いがあるかということです。メーリングリストのアーカイブを見てください。多くのことが起こっていますか？おそらく、次善のフレームワークはより良いフレームワークに成長するでしょう。いずれにせよ、使用することを意図していない方法でフレームワークをプッシュすることになった場合は、専門家のコミュニティに質問してもらうのは良いことです。