2009-06-27 40 views
4

最初のテストでは、GDI +(VB.NETでの記述)が自分の目的にとって十分に速くないことが示されています。私のアプリケーションでは、毎秒20フレーム以上のフルスクリーン解像度で何万個もの粒子(色付き円、非常に好ましくはアンチエイリアス処理済み)を描画できる必要があります。DotNETの超高速描画

私はGDI +の他の高度な描画機能(ダッシュパターン、画像、テキスト、パス、塗りつぶし)の多くを必要とするため、GDI +から離れることを躊躇しています。

OpenGL、DirectX、またはその他のプラットフォームを使用してVB.NETからパーティクルレンダリングを高速化する方法については、よくお尋ねください。私のアプリは厳密に2Dです。

のれん、 デビッド

答えて

3

VB.NETを使用する場合は、XNAまたはSlimDXを使用できます。

GDI +とXNAでゲームを作成した経験があり、GDI +が問題を引き起こしていることがわかります。 XNAをチェックアウトする場所はGDI +よりもはるかに高速です。なぜなら実際にビデオカードを使用して描画するためです。

SlimDXもうまく見えますが、私はそれを経験していません。 SlimDXは基本的にDirectX API for .NETです。

+1

XNAの以前のバージョンでは、WinFormsアプリケーションとXNAを混在させることは非常に困難でした。私の知る限り、これは現在サポートされています。 – rein

+0

あなたたちは金色です!本当にありがとう。私は1週間ほど忙しく、このようなことをすべて試してみる。 –

3

必要な速度を取得する唯一の方法は、OpenGLやDirectXのに移動する意味があること、残念ながら...ハードウェアレンダリングにソフトウェアレンダリングから離れるとすることです。

代わりに、グラフィックスルーチンを最適化して、画面/ウィンドウ全体ではなく、描画する必要があるパーティクルのみを描画するようにしてください。

私はJaredParに、新しいフレームワークへの巨大な切り替えを行う前に、既存のコードベースを改善できるかどうかを最初にプロファイリングすることをお勧めします。あなたがそれに精通していない場合、DirectXは最も簡単なフレームワークではありません。

+0

残念ながら、全体の粒子雲が同時に表示されていることが重要です。ユーザーがズームインすると、多くのパーティクル(OcTreesと2Dグリッドに格納されているのでパーツが簡単になります)を破棄できますが、完全にズームアウトされたビューでもうまく動作しなければなりません。 同じメモリビットマップ上でGDI +と-say- DirectXの両方を使用することはできますか?または、これらの2つのSDK間でピクセルをブリッジする時間が無駄になりますか? –

+1

私はGDI +とDirectXを同じメモリビットマップ上で使用することはできないと考えています。その1つはグラフィックスカードによってレンダリングされ、もう1つはソフトウェアによってレンダリングされます。 DirectXを描画しているものと同じhWndにGDI +を描画することはできますが、それらを同期させるのは少し難しい場合があります。 – rein

2

問題はGDI +ではなくアルゴリズムにある可能性があります。プロファイリングは確かに知る唯一の方法です。プロファイルがなければ、新しいGUIフレームワークに切り替わり、まったく同じ問題にぶつかります。

プロファイルを実行した場合、GDI +のどの部分が問題を引き起こしていましたか?

+1

私はこのコードですべての最適化をスローしましたが、私は認識していますが、表示コードを適切にプロファイルすることはできませんでした。私は、パフォーマンスに敏感なコードにプロファイリングを追加すると、実際のパフォーマンスを変更することになります(私は、粒子物理学者が同様の問題で苦労していると思います)。 フルスクリーン描画では問題ありません。私がいくつかのパーティクルだけをレンダリングすると、リフレッシュレートは非常に許容されます。 パーティクルを塗りつぶした楕円として、単一のGraphicsPathとして描画し、正確なピクセル深度と解像度を持つスプライトでDrawBitmapを使用しようとしました。 –

+0

@ David-Rutten:解決したことはありますか?あなたのコメントを読んで、私はあなたのプロファイリングがそれを遅くしないことを期待しないでくださいと言う必要があります。 *それは問題ではありません*重要なことは、各ルーチンやコード行の時間の割合です。そのルーチンやコード行がなければ保存されるためです。時間によって私は*壁時計の時間*を意味します。サンプリングがスレッド内のCPU時間に制限されていると、システムコールに時間がかかることがあります。 –

+0

@Mike:私はこれをGDI +で解決することはできませんでした。動的再描画中の表示を劣化させることは、私の頭を包み込むことができる唯一の解決策であるようです。私はGTK +を今見ていますが、最近私の仕事は私の方が良くなり、UIコードからコア開発に戻ってきました。 –

1

VB.netで作業しているので、WPF(.NETの部分は3.0以降)を使ってみましたか? WPFはGDI +ではなくDirectXに基づいているため、WPFの開発はまったく簡単なことではありませんが、必要な速度が得られるはずです。

+0

私はまだいませんが、私は今になります。先端に感謝します。 これまでDotNET2.0を使用していましたが、私が切り替えることはできません。 –

2

私が見つけた最も重要な速度増加、GDI +でゲームメーカーを書くとき、Format32bppPArgbに私のビットマップを変換することでした。 -

SuperFastBitmap = ConvertImagePixelFormat(SlowBitmap、Imaging.PixelFormat.Format32bppPArgb)

の場合彼らはすでにこの形式ではない、あなたは変換するとすぐに違いが表示されます。

+0

これはゲラットです。ありがとう。この効果がなぜ発生するのか知っていますか? – BudBrot

2

ヤレッドが言ったように、 サイクルのかなりの部分がGDIに入っていない可能性があり、それらを減らすことができるかもしれません。

それらを見つける簡単な方法は、ランダムに数回停止してスタックを調べることです。あなたが時間を無駄にするという行為の中でそれを捕まえる可能性は、時間の無駄に等しいです。

このような複数のサンプルに表示される命令や呼び出し命令は、置き換えることができれば高速化します。

In general, the method is this.

0

GDI +は、グラフィックスカードによって動かされていないので、それがレンダリングするためにCPUを使用しているため、それはレンダリングに時間がかかります。少なくとも、DirectXまたはSlimDXを使用することができます。

(悪い英語のため申し訳ありません)


これを参照してください:http://msdn.microsoft.com/en-us/library/windows/desktop/ff729480%28v=vs.85%29.aspx http://www.codeproject.com/Articles/159586/Starting-DirectX-with-Visual-Basic-NET

関連する問題