問題タブ [gdi]

サイズが変更されるダイアログがあります。また、WM_ERASEBKGND 呼び出し (現在は FillSolidRect への単純な呼び出し) に応答してペイントするカスタム背景もあります。

ダイアログのサイズを変更すると、途方もないちらつきが発生します。ちらつきを減らすために、すべての子ウィンドウを列挙してクリッピング領域に追加します。これで少しは改善されたようです。今では、すべての子コントロールが再描画されるときにちらつきがほとんど明らかになっています。

サイズ変更中にダイアログがちらつかないようにするにはどうすればよいですか? ダブルバッファリングが役割を果たさなければならないと思いますが、子コントロールを持つダイアログでそれを行う方法がわかりません(すべての子コントロールをオーナー描画などにしないでください)。

純粋な Win32 ベースのソリューションは歓迎されますが、私は C++ (.NET ではない) と MFC を使用していることに注意してください :)

注：私が試したものの、うまくいかなかった（理由がわからない）ことの1つは次のとおりです。

TransparentBlt を使用するには、どのライブラリを含める必要がありますか?

これは、Gdi32.lib にリンクする VC98 (Visual Studio 6) です。(BitBlt などの他の GDI 関数は期待どおりにリンクします)、コンパイラはエラーや警告なしでコンパイルします。

Gdi32.lib が含まれていても、リンカーは次のエラーを返します。

私は何が欠けていますか？

DrawFrameControl() は Font オブジェクトと Brush オブジェクトを作成し、それらを dc に選択し、削除しないようです。(BoundsChecker メッセージによる)。誰かがそのようなことに直面しましたか？

C# では、ウィンドウ ( IntPtr ) へのハンドルがあり、そのウィンドウの背景色を変更したいと考えています。これどうやってするの？

次のように、そのハンドルの GDI グラフィックス オブジェクトを取得できます。

Graphics graphics = Graphics.FromHwnd(theHandle);

だから私はどういうわけかこれから背景色を変えることができるはずですか？

また、ウィンドウの移動、サイズ変更、再描画などを行った後でも背景色が維持されるようにしたいと考えています。

Win32 GDI で CDC ラッピングを使用して画面に表示および印刷する成熟した MFC C++ アプリケーションがあります。何年にもわたって最適化されてきましたが、もう少し速いものに置き換えたいと思います。グラフィックには、レンダリングされた三角形のサーフェス モデル、複雑なポリラインとポリゴン、および大量のテキストが含まれていました。次の基準を満たす必要があります。

• 表示されるベクトルの数は非常に多くなる可能性があります。たとえば、単一のサーフェス三角形は、レンダリング時に多数の線と塗りつぶしを生成する可能性があります。現在、この情報はどこにも保存されておらず、オンザフライで生成および描画されます。SDK は、バッファリングされるベクトルの総数を制限することをサポートする必要があります。そうしないと、メモリ不足になりがちです。

• SDK は、CView および ScrollView クラスを含む任意の CWnd 派生クラスにレンダリングできる必要があります。

• SDK は、すべての Windows 印刷デバイスへの印刷をサポートする必要があります。

• SDK は、低レベルの CDC / GDI 呼び出しからの移植を比較的簡単にするのに十分なほど低レベルである必要があります。

• オープンソースは常に素晴らしいものですが、オプションのアップグレード/サポート付きで、最大 2,000 ドルの 1 回限りの費用も問題ありません。ユーザーあたりのライセンス費用は受け入れられません。

• ソース コードへのアクセスは、特に Windows CE / Mobile で SDK の一部を実行するというアイデアを考えれば、大きなボーナスです。

• 私は現在、3D から 2D ビューポートへの独自の管理を行っています。適切な低レベルの SDK が利用できない場合は、高レベルの SDK で 3D を適切に処理し、32 ビット Windows プラットフォームで数百万の三角形、多角形、およびテキスト エンティティを処理する必要があります。

助言がありますか？提案された提案に具体的な長所と短所を記載していただければ幸いです。

私は現在学生で、Visual C++ アプリケーションを設計して、グラフのマトリックスを含むテキスト ファイルを作成するために、有向グラフを視覚的に挿入できるようにしようとしています。この時点で、onClick イベントを作成してノードを作成し、フォームの Paint イベントを使用してノードを描画しました。また、ノードが重ならないように条件を挿入しました。

現在、ノード間のリンクの作成に取り組んでいます。私が遭遇した問題は、2 つのノードを結ぶ線が別のノードと交差することです。この状況では、オーバーラップを検出し、それを回避するためにラインがどれだけアーチする必要があるかを計算するアルゴリズムを作成するのは面倒だと思います。

したがって、クリックして左右にドラッグすることでユーザーがアーチ状にできる線を作成することを考えましたが、これを行う方法に関するチュートリアルを見つけるのに問題がありました. したがって、誰かがプロジェクトでこの種のアーチ ラインを導入しなければならなかったことがある場合、またはこれに関する情報をどこで見つけることができるかを知っている場合は、深く感謝します.

言及:

1. このプログラムにサードパーティのものをインストールすることに興味がないので、これを行うための派手なグラフィック ライブラリをお勧めしないでください。コードを挿入したい関数は form1_onPaint のような名前になっているので、C++ 標準ライブラリに厳密に準拠したいと考えています。
2. クリックとドラッグで線を描くことに興味があると言ったことは知っていますが、 onPaint イベントのオーバーラップを検出する機能や、これを解決するために使用できるその他の機能など、これに対する別の実行可能な解決策を誰かが提案できれば、それは大いに役立ちます。

MSDN のドキュメントは、GDI ペンに関する次の 2 つの事実について (ある程度) 明確です。

1. コスメティック ペン (CreatePen または ExtCreatePen w/ PS_COSMETIC で作成) は 1単位幅でなければなりません (まあ、<= 1 ですが、そこには行きません)。

2. 幾何学的 (ExtCreatePen w/ PS_GEOMETRIC) ペンはソリッドでなければなりません (PS_SOLID のみ、PS_DASH は不可など)。ただし、太い線を描くことはできます。 これは、上記のリンクに9倍の制限として明確に文書化されています（私はばかです）。私の弁護のために、私のコードの（悪い）コメントと（壊れた）ロジックは、そうではないと信じさせました。他のいくつかのグーグル記事は、Windows 9x のみを考慮して書かれているに違いありません。

これらのルールに違反して、GDI がこれらのペンで楽しく描画できるのはなぜですか?

太い (たとえば、幅 = 10) 化粧ペンと破線の幾何学ペンを作成できます。なんてこった、太くて破線の幾何学的なペンを作成できます!

これらのペンは、通常は正常に動作するようです。私が見た唯一の問題は、非常に大きな点の配列を渡すときの Polyline です。線のレンダリングが非常に遅くなります。ただし、Polyline は、一般に大きな配列では奇妙な動作をします。悪いペンでは動作が異なります。（私の他のポリラインの問題は別の質問かもしれません...）

幅広のコスメティック ペンやパターン付きの幅広のジオメトリックを使用しても安全ですか?

C# で GDI を使用して、画像からピクセルあたり 1 ビットのマスクを作成するにはどうすればよいですか? マスクを作成しようとしている画像は、System.Drawing.Graphics オブジェクトに保持されています。

Get/SetPixel をループで使用する例を見たことがありますが、これは遅すぎます。私が興味を持っているのは、このような BitBlits のみを使用する方法です。私はそれをC＃で動作させることができません。どんな助けも大歓迎です。

Windowsで画面のDPIを取得する場合（:: GetDeviceCapsを使用）、水平方向の値は常に垂直方向の値と同じになりますか？例えば：

これらの値はこれまでに異なりますか？

GDI ウィンドウ ハンドルを追跡して下げる最良の方法は何ですか。.