問題タブ [gdi]

GDI 呼び出しを監視できるツールはありますか?

現在のデバイス コンテキストでのシステムのデフォルトのポリゴン塗りつぶしモードはALTERNATE(Windows プログラミングに関する Petzold の本から学んだように) でありPolygon、モードを で変更しない限り、Win32 関数で使用されますSetPolyFillMode。

私の質問は次のとおりです: GDI+ Graphics::FillPolygon(FillModeシグネチャにパラメータなし) メソッドも現在のデバイス コンテキスト フィル モードを使用するか、既知の既定値を設定してから、呼び出される前に設定されたモードに戻しますか?

ありがとう！

MSDN では、CreatePatternBrush について次のように表示されます。

DeleteObject 関数を使用すると、関連するビットマップに影響を与えずにパターン ブラシを削除できます。したがって、このビットマップを使用して、任意の数のパターン ブラシを作成できます。

私の質問は反対です。HBRUSH が長期間使用されている場合、ブラシを作成した直後に HBITMAP を削除できますか? IE: HBRUSH は HBITMAP の独自のコピーを保存しますか?

この場合、HBRUSH にはオブジェクト スコープを持たせ、HBITMAP にはメソッド スコープ (HBRUSH を作成するメソッド) を持たせたいと思います。

DrawFrameControlを使用して、古い学校（テーマなし-テーマ付きラジオはまったく別の問題です）ラジオボタンを自分で描いています：

私は、RECT に何を渡すかを決定する確実な方法を見つけることができませんでした。私は 12x12 の長方形を使用していますが、Windows にラジオ ボタンのサイズを教えてもらいたいと思っています。

DrawFrameControl は、通過する四角形に合わせてラジオ ボタンをスケーリングするように見えるので、ラジオの「正しい」サイズに近づける必要があります。画面上の他の (非所有者が描いた) ラジオから離れて見えます。

誰でもこれを行う方法を知っていますか?

私はc＃2005を使用しています。画像に斜めに文字列を書きたいです。ただし、デフォルトでは、c# は横書きまたは縦書きのオプションを提供します。

斜めに書く方法は？

ありがとう

GDI をリークしていると思われるアプリケーションのクラッシュ ダンプがあります。アプリは XP で実行されており、WinDbg に読み込んで確認しても問題ありません。以前は、Gdikdx.dll 拡張機能を使用して Gdi情報を確認していましたが、この拡張機能は XP または Vista ではサポートされていません。

WinDbg で GDI オブジェクトの使用法を見つけるためのポインタはありますか。

または、失敗したプログラム (およびそのストレス テスト スイート) にアクセスできるので、XP および Vista (または Windows 2000 のターゲットではありません) 用の「ライブ」デバッグ ツールを知っていれば、実行中のシステムで再現できます。 .

助けてください！私は本当に頭が痛いです。私のプログラムは、ちょっとした個人的なノート マネージャーです (Google で「cintanotes」を検索)。一部のコンピューター (もちろん私は所有していません) では、起動直後に未処理の例外でクラッシュします。AMD CPU を搭載する傾向があることを除けば、これらのコンピューターについて特別なことは何も言えません。

環境: Windows XP、Visual C++ 2005/2008、raw WinApi。

この「Heisenbug」について確かなことは次のとおりです。

1) クラッシュはリリース バージョンでのみ発生します。

2) GDI 関連のものをすべて削除すると、クラッシュはすぐになくなります。

3) BoundChecker には文句はありません。

4) ログを書くと、ローカルの int 変数の宣言でクラッシュが発生したことがわかります! それはどうしてですか？メモリの破損？

どんなアイデアでも大歓迎です！

更新: 「障害のある」PC でアプリをデバッグすることができました。結果：

「CintaNotes.exe の 0x0044a26a で未処理の例外: 0xC000001D: 不正な命令。」

そしてコードが壊れる

0044A26A cvtsi2sd xmm1,dword ptr [esp+14h]

したがって、問題は「コード生成/拡張命令セットを有効にする」コンパイラオプションにあったようです。「/arch:SSE2」に設定され、SSE2 をサポートしていないマシンでクラッシュしていました。このオプションを「未設定」に設定したところ、バグはなくなりました。ふぅ！

助けてくれてありがとう！

「Big Windows」では GDI ハンドルが一意であり、プロセス固有であることは知っていますが、Windows CE 6.0 でも同じように機能しますか?

例: 私は、他のいくつかのサービスやアプリケーションが使用するフォント管理サービスを持っています。このサービスには、印刷と表示に有効なフォントと構成のリストがあります。それぞれで CreateFontIndirect() が呼び出されています。これらのクライアント アプリケーションのいずれかが特定のフォント (および構成) を要求した場合、適切な HFONT を返すことはできますか? そうでない場合、ハンドルを複製する安全で有効な方法はありますか。カーネル ハンドルの場合は DuplicateHandle です。

私が尋ねる理由は、PostMessage を介して別のアプリケーションに渡された HFONT が正しく動作するのを見たことがありますが、それらが「想定」されているとは思わなかったからです。

CDC派生クラスを使用してビットマップに書き込むことにより、C ++ MFCアプリケーションで大きな（たとえば20,000 x 20,000）ピクセルのビットマップを作成できるようにしたいと思います。MSDNのドキュメントで説明されているようにメモリDCを使用しようとしましたが、これらは現在のディスプレイドライバと互換性のあるサイズに制限されているようです。

私は現在、ビットマップ印刷ドライバーを使用して作業を行っていますが、GDI情報をスプールするため、非常に低速で、非常に大量の中間ストレージを使用します。

私が描いているモデルはレンダリングに何百万ものGDI呼び出しを必要とするため、私が探しているソリューションにはメタファイルやスプーリングは含まれていません。

複数のメモリDCを介して分割統治法を使用することもできますが、それはかなり面倒でエレガントでない手法のようです。

何かご意見は？

この質問の背景を簡単に説明すると、職場では Dell Precision ワークステーションを使用しています。私の現在のものはNVidia Quadro FX1700を持っています。私のチームは、リアルタイム データ取得システム用のグラフィックス コンポーネントを開発しています。そのため、グラフィック操作が CPU 時間を使いすぎていないかどうかを常に確認しています。簡単なチェックのために、いくつかのテスト プログラムを実行して、指定されたレート (たとえば 10 fps ) でシーンを描画し、従来のタスク マネージャーを使用して CPU 使用率を確認します。これらのプログラムの 1 つは、GDI の DrawRectangle 呼び出し (塗りつぶされている) に重きを置いています。このプログラムは常に約 40% の CPU ユーザー時間を消費していましたが、約 1 年ほど (ここで推測するだけです) 約 2-3% のカーネル時間しか使用していません。明らかに、ハードウェア アクセラレーションがここで行われています。実際、HW アクセルをオフにすると、元の 40% のユーザー時間に戻ります。もちろん、これはすべて朗報です。OpenGL への移行をすでに考えていたからです。毎年、GDI はハードウェア アクセラレーションの恩恵を受けませんでした。少し前まではそうです。

これについてもっと知っている人はいますか？マイクロソフトはこれを行いましたか? それともgfxカードのベンダー固有ですか？

編集

すでに回答が寄せられていますが (Ferrucio、Torlack、Rob Walker)、私の質問にはまだ回答がありません。ここでは、塗りつぶされた四角形について話しています。おそらく、最適化する最も簡単な機能です。GPU にいくつかの座標を送信し、リッピングするだけです。それでも、それは常に CPU 側で実装されていました。これまでの回答から、NVidia がついに (10 年以上経って) 光を見て、GDI を加速したと信じるようになりました。そして、これについての発表はありませんか？これに関しては全く情報がありません。社内の顧客からグラフィックスの高速化について尋ねられますが、私が言えるのは「運が良かった」ということだけです。

編集2

さまざまな回答によると、ドライバーに関連しているようです。そのため、NVidia は何年にもわたってワークステーション カード用の粗悪な GDI ドライバを作成してきました。GDI が高速化されていないことは、社内で認められた事実であり、すべてのテストでこれが確認されました。