2

私は、多くの DIB ビットマップ (によって作成されたCreateDIBSection) を持ち、Win API を使用してそれらに多くのテキストを描画する必要があるプログラムに取り組んでいます。

ビットマップ上に描画するために、Windows は によって作成されたデバイス コンテキストを必要としますCreateCompatibleDC。

そして今、ここに2つのアプローチがあります：

  1. ビットマップごとに 1 回 DC を作成し、それを描画に使用して、ビットマップを解放するときに削除できます。

  2. または、ビットマップに描画する必要がある場合にのみ DC を作成し、描画関数を呼び出して DC を削除できます。

より良いアプローチは何ですか？呼び出しが少ないため、最初の方法を好みます。これにより、コードがはるかに小さくなり、少し速くなります。

しかし、ビットマップごとに長寿命の DC を保持するにはコストがかかりすぎませんか?

Edit1: アプリケーションは実際には GUI ツールキット ライブラリであり、将来的にはさまざまな予測不可能な方法で使用できるため、パフォーマンスを最大限に高め、システム リソースの使用を最小限に抑えるバランスの取れた決定が必要です。

4

2 に答える 2

4

GDI オブジェクトは、プロセスごととセッションごとの両方で制限されています。同じセッションで実行されている他のすべてのプロセスとリソースを競合しています。そのことを念頭に置いて、必要な場合にのみ GDI リソースを消費する必要があります (質問のオプション 2)。

Mark Russinovich のブログ エントリ、Pushing the Limits of Windows: USER and GDI Objects – Part 2 では、かなりの詳細が説明されています。要点をまとめると、ウィンドウ マネージャーが GDI リソースに設定する制限の一覧を次に示します。

  • プロセスごとに 10.000 GDI オブジェクト (既定値、レジストリ キーHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuotaで構成可能)。
  • ユーザー セッションあたり 65.535 個の GDI オブジェクト。
  • GDI オブジェクトのメモリ制限は、ページ プールの制限です (「Windows の限界を押し上げる: ページ プールと非ページプール」を参照してください)。
于 2015-11-02T08:56:27.960 に答える