私がしていることは、多数のビットマップを単一のビットマップにレンダリングすることです。何百もの画像が存在する可能性があり、レンダリングされるビットマップは 1000x1000 ピクセルを超える可能性があります。
複数のスレッドを使用してこのプロセスを高速化することを望んでいますが、Bitmap オブジェクトはスレッドセーフではないため、同時に直接レンダリングすることはできません。私が考えているのは、大きなビットマップを CPU ごとにセクションに分割し、それらを個別にレンダリングしてから、最後に再び結合することです。皆さん/女の子がより良い提案を持っている場合に備えて、私はまだこれを行っていません.
何か案は？ありがとう
Lee さん、Image GDI+ オブジェクトを使用する場合は、すべての作業を 2 回行うことになります。複数のスレッドで生成したセクションは、分割統治アプローチの最後に再構築する必要がありますが、そもそも分割の目的が無効になるのではないでしょうか?
この問題は、ビットマップ セクションのそれぞれでかなり複雑なことを行っている場合にのみ克服できます。これは、画像のサブパーツを大きなビットマップに単純に再描画するよりもはるかに多くの処理時間を必要とし、すべての問題を解決する必要はありません。
それが役立つことを願っています。どのようなイメージ レンダリングを計画していますか?
1つのアプローチは、すべての小さなビットマップをersatzビットマップにレンダリングすることです。これは2次元int配列になります（Bitmapとにかく実際にはそうです）。すべての小さなビットマップが大きな配列に結合されたら、大きな配列からBitmap同じ次元の実数への1回限りのコピーを実行します。
「実際の」GDI+ビットマップを作成するために使用できるメモリは非常に限られているため、Windowsモバイルデバイスの複雑なグラフィックスには常にこのアプローチ（マルチスレッドの側面は含まない）を使用します。
Bitmap当初の意図どおりにを 使用することもできます。Bitmapスレッドセーフであることが保証されているわけではありませんが、2つのスレッドがビットマップの同じ部分を上書きしないことを保証できる限り、それが問題になるかどうかはわかりません。少なくとも試してみます。
更新： 質問を読み直したところ、マルチスレッド化することで、これらの操作の全体的な速度が（あるとしても）それほど向上しない可能性があることに気付きました。これは、1か月で赤ちゃんを作ることができない古典的な9人の女性の問題です。
各スレッドにバイト配列への書き込みをさせることができ、それらがすべて終了したら、単一のスレッドを使用してバイト配列からビットマップ オブジェクトを作成します。他のすべての処理が事前に行われている場合、それはかなり迅速なはずです。
私は似たようなことをしましたが、私の場合、各スレッドは x (画像のサイズとスレッドの数によって異なります) をロックし、画像内の多くのビット行を保持し、スレッドが存在しないようにそれらのビットに書き込みを行います。彼らの書き込みを重ねました。