問題タブ [gdi]

基本的に、GDI+ を使用するように設定されているオフスクリーン DC にレンダリングするように呼び出されています (方法はわかりません)。OpenGL コンテキストを DC に関連付けようとすると、失敗します (つまり、ゼロを返しますが、エラーはありません)。SetPixelFormat も失敗します (おそらく、既に設定されているためでしょうか?)、ここでもエラーではなくゼロが返されます。

そのような状況 (つまり、他の誰かが GDI+ を使用しているウィンドウのオフスクリーン コンテキスト) を考慮して、OpenGL コンテキストを作成し、自分のレンダリングに OpenGL を使用することが可能かどうかは誰でも知っていますか? (可能であれば、なぜ wglCreateContext が失敗するのでしょうか?)

高性能を実現するために、大きな CompatibleDC を作成し、その上に大きな画像を描画してから、画像の一部を他の DC に bitblt したいと考えています。

次のコードを使用して、互換性のあるメモリ DC を作成しています。しかし、rect が 5000*5000 などのように非常に大きくなると、作成された CompatibleDC が不安定になります。うまくいくこともあれば、失敗することもあります。私のコードに何か問題がありますか？

グリッドのあるコントロールがあります。デバイスコンテキストクラスの描画線関数を使用して、グリッドを構成する水平線と垂直線を毎回描画する方がコストがかかりますか、それとも、グリッドをメモリデバイスコンテキストに一度描画してから、毎回ブリットする方が高速ですか？ウィンドウDC？ありがとう。

GDIを使用してフォントを作成する一般的な方法は、次のように目的のポイントサイズとターゲットデバイスの垂直解像度（DPI）を使用することです。

デフォルトのMM_TEXTマッピングモードを想定すると、これはpoint_sizeを目的のデバイスのピクセルの高さに変換します。（これは一般的な概算です。実際には、72ではなく1インチに72.27ポイントがあります。）（マイナス記号は、セルの高さではなく、実際の文字の高さを指定することを意味します。）

横向きのフォント（つまり、方向とエスケープメントが90度のフォント）を作成する場合は、LOGPIXELSXではなく使用しLOGPIXELSYますか？私がターゲットにしているプリンターの中には、水平解像度と垂直解像度が異なるものがあります。

一般的に、角度が必要な場合は、とthetaを組み合わせますか？私はこのようなことを考えています：LOGPIXELSXLOGPIXELSY

これは私には直感的に理解できますが、これが実際にGDIフォントマッパーとプリンタードライバーがどのように機能するのか疑問に思っています。

サイズが 1x16 の Image オブジェクトをメモリにレンダリングしようとしています。この画像は、タイル張りの背景として使用されます。グラデーション自体は、非線形の方法で 3 つの色を持つ必要があります。

ピクセル 1 ～ 6: グラデーション カラー 1 ～ カラー 2

ピクセル 7 ～ 16: グラデーション カラー 3 ～ カラー 4

親ウィンドウと子ウィンドウは同じサイズです。そして、親は、子が再描画するとき、親が再描画するときに、子の再描画を聞きます。そのため、invalidate を使用して親ウィンドウを消去することはできません。これにより、wm_paint が子ウィンドウに送信され、無限のサイクルが繰り返されます。

invalidateRect、invalidateRgnなどを使用せずに親widnowをクリーンアップするにはどうすればよいですか。または、 wm_paint を子ウィンドウに送信せずに親を無効にするにはどうすればよいですか?

どうも！

ユーザーがいくつかのインターフェイス アイテムをドラッグできるようにしたいと考えています。現時点では、Cursor.Draw メソッドを使用してグラフィックス オブジェクトに直接描画できるように見えるだけです。ウィンドウからウィンドウへ、およびタスクバー上でドラッグできるフォルダーなどの Windows アイコンをドラッグする方法で、画面上でドラッグされているアイテムを表示できるようにしたいと考えています。dotnet フレームワークはこれを行う機能を提供しますか?それとも恐ろしい Windows API 関数へのフックがたくさん必要になるでしょうか?

編集: ものをドラッグしているときに、マウスカーソルの横に表示されているドラッグしているものの画像を見ることができるようにしたい。項目をウィンドウの外にドラッグして、マウス カーソルの横に表示し続けられるようにしたいと考えています。

GDI+ で保持モード描画アプリケーションを開発しています。アプリケーションは、単純な形状をキャンバスに描画し、基本的な編集を実行できます。これを行う計算は最後のバイトに最適化されており、問題ではありません。組み込みの Controlstyles.DoubleBuffer を使用しているパネルに描画しています。

大きなモニター (私の場合は HD) でアプリを最大化して実行すると、問題が発生します。(大きな) キャンバスの 1 つの角から対角線上にあるもう一方の角まで線を引こうとすると、遅延が始まり、CPU が高くなります。

アプリの各グラフィカル オブジェクトにはバウンディング ボックスがあります。したがって、最大化されたアプリの 1 つのコーナーから対角線の反対側のコーナーに向かう線のバウンディング ボックスを無効にすると、そのバウンディング ボックスは実質的にキャンバスと同じ大きさになります。ユーザーが線を描いているとき、境界ボックスの無効化はこのように mousemove イベントで発生し、明確なラグが表示されます。このラグは、キャンバス上のオブジェクトが線のみの場合にも存在します。

これをさまざまな方法で最適化しようとしました。より短い線を引くと、CPU とラグが減少します。Invalidate() を削除して他のすべてのコードを保持すると、アプリは高速になります。バウンディングボックスの代わりに Region (図にまたがるだけ) を使用して無効化すると、同じように遅くなります。バウンディング ボックスを、背中合わせに配置された小さなボックスの範囲に分割して、無効化領域を減らした場合、目に見えるパフォーマンスの向上は見られません。

したがって、私はここで途方に暮れています。無効化をスピードアップするにはどうすればよいですか?

余談ですが、Paint.Net と Mspaint の両方に同じ欠点があります。ただし、Word と PowerPoint は、上記のように遅延も CPU 負荷もまったく発生せずに線を描くことができるようです。したがって、望ましい結果を達成することは可能ですが、問題はどのようにですか?

レイヤー効果を作成するために、さまざまなオブジェクトによって描画される 1 つのウィンドウがあります (1 つのオブジェクトがコンパスを描画し、もう 1 つのオブジェクトがグリッド線を描画し、別のオブジェクトが高度計の読み取り値などを描画するヘッドアップ ディスプレイを考えてみてください)。そのため、各オブジェクトには描画先の黒いメモリ ビットマップがあります。そのオブジェクトの Draw 関数を呼び出すと、メモリ ビットマップがアプリケーション ウィンドウにブリットされます。メモリ ビットマップは最初はすべて黒で、オブジェクトはその上に描画されます。黒は透明色なのでマスキングしています。結果はオーバーレイ効果です。

そのため、blt() 関数の論理関数として OR を使用してきましたが、うまくいきました。しかし、前のレイヤーが白く塗られている場合、その上に描画するレイヤーが前のレイヤーの下にあるかのように見えることに気付きました。この効果が発生するのは白（っぽい）の色だけです。他のすべての色は正しくペイントされています (つまり、レイヤーは前のレイヤーの上にペイントされているように見えます)。誰もこの現象を見たことがありますか？

かなりグラフィックを多用するアプリケーション（C ++またはC＃、グラフィックAPIは未定）を開発していたとすると、ほとんどの使用はRDP（ターミナルサーバーセッションまたはシングルユーザーマシンへのリモートアクセス）を介したリモートユーザーによるものになります。本質的でない「目玉」効果やアニメーションは避けるべきであることは明らかです。私の質問は次のとおりです。

• RDPプロトコルを最も効率的に使用するには、何をするか、または避けるように注意する必要がありますか？（たとえば、RDPが一部のグラフィックス描画プリミティブをクライアントに直接リモートできるという考えがあります...しかし、それはGDIの場合のみですか？ダブルバッファリングを使用すると、そのようなリモート処理が中断され、ビットマップモードが強制されますか？クライアント側のビットマップキャッシュは「動作します」またはフォントやアイコンなどの特定のもののみをキャッシュしますか？）

• RDPストリームが実際に何を転送しているのか（特に、ビットマップと描画プリミティブ）についての洞察を与える、利用可能なRDPプロトコルアナライザーの種類はありますか？（これを行うためにrdesktopソースにいくつかのインストルメンテーションを追加することを想像できますが、おそらく何かがすでに存在します）。