問題タブ [drawingcontext]

いくつかの画像を含むキャンバスがあり、DrawGeometry も使用して、時間が経過すると塗りつぶされる円を描画します。

これは、DrawingContext で円を描く方法です。

InvalidateVisual(); を呼び出します。それを呼び出すために。

しかし、これを行うと、私の円は私の画像の後ろにあり、見ることができません。どうすればそれらの前に描くことができますか?

私はWPFにまったく慣れていないので、苦労しています....

これは、要求された他のメソッド コードです。

これは私の最初の質問ですが、私は長い間潜んでいます。これを 2 つの部分に分けて説明します。1 つの部分では、私が何をしているのか、なぜこれが進むべき道だと思うのかを説明します。2 つ目は、自分では解決できない実際の問題です。

私は何をやっている？ 私は現在、リアルタイムで表示されることを意図した 2 次元の機能をレンダリングするためのフレームワークを開発しています。ブラウザの Google マップのようなアプリケーションを考えることができますが、フレームワークはあらゆる種類の地理データをレンダリングすることを意図しています (Google タイルのような軸に沿ったラスター データだけではありません)。

このフレームワークは、デスクトップおよびラップトップ用の WPF アプリケーションである当社 (会社) の最新製品に統合される予定です。

したがって、実際にジオメトリのみをレンダリングするために WPF を選択しました。Visibility と Occlusion Culling は自分で行い、入力処理 (マウス ピッキング) やカメラの移動なども行っています。

リアルタイム アプリケーションであるため、少なくとも 30 FPS を達成する必要があります。このフレームワークは、画像をレンダリングするときに適切に機能します。フレームごとに数千のビットマップを問題なく描画できますが、ポリゴン データが大きな問題であることが判明しました。

WPFを使用して、特にDrawingContextとStreamGeometryを使用して、かなりの量のポリラインとポリゴンデータをレンダリングしている実際の質問。これまでの私の理解では、これがパフォーマンスが必要な場合の方法です。しかし、私はこれから期待した結果を達成することができません。

これは、StreamGeometry に実際のデータを入力する方法です。

そして、これが私のジオメトリを描く方法です:

テストとして、OpenStreetMap から ESRI シェイプをアプリケーションにロードしてパフォーマンスをテストしましたが、まったく満足できませんでした。テスト データは、合計 20,000 ラインの 3500 ライン セグメントで構成されています。

各セグメントを独自の StreamGeometry にマッピングするとパフォーマンスが非常に悪くなりますが、私はすでにそれを期待していました: レンダリングには約 14 秒かかります。

次に、複数の数値を使用して、より多くのセグメントを同じ StreamGeometry にパックしようとしました: 80 StreamGeometry、レンダリングには約 50 ミリ秒かかります。

しかし、これ以上の結果は得られません。行数を約 100k に増やすと、アプリケーションがほとんど使用できなくなります。レンダリングに 100 ミリ秒以上かかります。 ベクター データをレンダリングするときに、ジオメトリとペンの両方をフリーズする以外に何ができますか?

何かがひどく間違っているように見えるので、WPFに頼るよりも自分でDirectXを利用したいところです。

編集

私が何をしているのかをさらに明確にするために: アプリケーションは、地理データをリアルタイムで視覚化します。これは、ブラウザーの Google マップのようなアプリケーションと非常によく似ています: ただし、はるかに多くのデータを視覚化する必要があります。ご存知かもしれませんが、Google マップではズームとパンの両方が可能です。滑らかなアニメーションとして表示するには、25 FPS を超える必要があります。それ以下は流暢に感じません。

※申し訳ありませんが、実際の製品がリリースされる前に、このビデオをアップロードするべきではありません。ただし、大量のベクター データ (ポリゴンとポリライン) を使用する Google マップのようなものを想像することもできます。*

2 つの解決策があり、そのうちの 1 つが非常に頻繁に述べられています。

重い描画をビットマップにキャッシュする

実装はちょっと簡単に思えますが、このアプローチにはいくつかの問題があります。パンニングを適切に実装するには、フレームごとに重いものを描画しないようにする必要があるため、パンニング中にキャッシュされたビットマップを更新しないという選択肢が残されていますカメラ、またはビューポートよりもさらに大きな領域をカバーするビットマップを作成するため、キャッシュされたビットマップを頻繁に更新するだけで済みます。

2 番目の「問題」は、ズームに関連しています。ただし、これは実際の問題というより視覚的なアーティファクトです。キャッシュされたビットマップは 30 FPS で適切に更新できないため、ズームするときもそれを避ける必要があります。ズーム中にビットマップをスケーリングし、ズームが終了したときにのみ新しいビットマップを作成することはできますが、ポリラインの幅は一定の厚さではありませんが、そうする必要があります。

このアプローチは MapInfo で使用されているようですが、あまり気に入っているとは言えません。ただし、実装するのが最も簡単なようです。

ジオメトリを異なる描画ビジュアルに分割する

このアプローチは、問題への対処方法が異なるようです。このアプローチがまったく機能するかどうかはわかりません。この領域で WPF がどのように機能するかを正しく理解しているかどうかにかかっています。描画する必要があるすべてのものに対して 1 つの DrawingVisual を使用する代わりに、いくつかを使用して、すべてを RenderOpened() にする必要がないようにする必要があります。カメラのパンと移動の両方を反映するために、上記のサンプルのマトリックスなどのパラメーターを変更するだけで済みます。ただし、このアプローチにもいくつかの問題があります。カメラをパンすると、必然的に新しいジオメトリがビューポートに表示されるため、最初のアプローチと同様のことを実行する必要があります。実際には、現在表示されていないが表示される可能性があるものをレンダリングしますカメラがシフトしたため。

両方のアプローチに関連する 問題 これらのアプローチのどちらも解決できない大きな問題の 1 つは、全体的なフレームレートが安定している場合でも、キャッシュされたビットマップを更新するときに時折ヒックアップすることです (キャッシュされたビットマップがカメラがパンされなくなったときに更新される)、または RenderOpen を呼び出してジオメトリの可視チャンクを描画することは避けられないようです。

これまでの私の考え

これらは私がこれまでに見たこの問題に対する唯一の 2 つの解決策であるため (私は 1 年以上にわたってかなりの割合でグーグル検索を行ってきました)、これまでのところ唯一の解決策は、最も強力な GPU でさえフレームレートのヒックアップを受け入れることだと思います。 (1 秒あたり数億のプリミティブをラスタライズできるはずです)、ビューポートの更新の遅延 (ビューポートが移動されなくなったときにのみビットマップが更新される場合)、または WPF をまったく使用せずに DirectX に頼る直接。

お役に立ててとてもうれしいですが、これまでのところ、WPF のレンダリング パフォーマンスに感銘を受けたとは言えません。

通常の WPF レンダリングをハイジャックして、コントロールをプリミティブに分割し、レイアウト管理を行い、バインディングなどを適用したいと思います。

私が理解している限り、WPF でのレンダリング全体は、依存関係プロパティ システムによって定義された値を使用して、レイアウト マネージャーによって計算された位置でのプリミティブ (テキスト、画像、線、曲線) のレンダリングに要約されます。独自のプリミティブ レンダリング ロジックを提供できれば、たとえばカスタム ドキュメント タイプにレンダリングしたり、ネットワーク経由で実際のレンダリング用にプリミティブを転送したりできます。

私の計画は次のとおりです。

1. カスタムを実装しますDrawingContext。は、、などDrawingContextの一連のメソッドを定義する抽象クラスです。この機能には、独自の実装を提供する必要があります。DrawEllipseDrawTextDrawImage
2. WPFUserControlを作成し、指定された .xml に強制的にレンダリングしますDrawingContext。

ただし、次の問題が発生しました。

1. DrawingContext簡単にオーバーライドできない抽象内部メソッドvoid PushGuidelineY1(double coordinate)とが含まれています。void PushGuidelineY2(double leadingCoordinate, double offsetToDrivenCoordinate)（もしかしたら、これを克服するためのトリックがあるのでしょうか？）
2. ビジュアル全体DrawingContextを?にレンダリングする方法はないようです。なんで？

私は次のようなことができます

—しかし、をレンダリングする直接的な方法があるのだろうかUIElement. (もちろん、この問題は小さな問題ですが、インフラストラクチャがないことを考えると、これが適切な方法であるかどうか疑問に思います。)

DrawingContextでは、から継承するためのものではありませんか? カスタムを提供するという全体的なアイデアはDrawingContext正しい方向への一歩ですか、それとも戦略を再考する必要がありますか? カスタム コンテキストへの描画は WPF でサポートされていますか、それとも別のインターセプト ポイントを探す必要がありますか?

この質問が以前に尋ねられなかったことを願っています。私はどこでも検索しました。

私の問題は、ポイントでwpfユーザーコントロールに一連の座標を描画していることです。ポリゴンを背景色で塗りつぶすことができましたが、ストロークでは塗りつぶしませんでした。ストークがなぜか描いてない？

DrawingContext を使用した OnRender イベントのコードは次のとおりです。

コードの詳細

StreamGeometry streamGeometry = new StreamGeometry();

}

詳細をお知らせいたします。

どうもありがとう。

寸法が 25.5"x11" (レター ページの 3 倍) の 600 DPI の「三つ折り」画像を作成する必要があります。そのために、DrawingVisual、DrawingContext、および RenderTargetBitmap クラスを通じて WPF Imaging を使用しています。

たとえば、400 DPI 以下の低解像度で画像を生成すると、すべてのテキストが期待どおりに正しい位置に表示されます。ただし、画像の解像度を 500 DPI レベル以上に上げると、画像の右端に配置された特定のテキストが単純に消え、他の相対的に配置されたテキスト/図形は完全に印刷されます。それについての最もクレイジーな部分は、DPI を変更しようとすると、異なるテキストが表示/非表示になることです。あるテスト ケースでは、600 DPI では描画された FormattedTexts の 1 つのセットが欠落し、650 DPI では描画された FormattedTexts の別のセットが欠落し、700 DPI ではすべて正常に印刷されます。

以下のコード スニペットで問題を再現しました。そのまま (600 DPI) 実行すると、非常に大きな白い画像が表示されます。Dpi 定数を 400 以下に変更すると、テキストが問題なく印刷されます。

DrawingVisual クラス (VisualBitmapScalingMode、VisualTextRenderingMode、VisualEdgeMode など) 内の多くのノブを回してみましたが、役に立たなかったことに注意してください。これらの設定に関する私の調査のほとんどは、テキストが消えるのではなく、「あいまいな」テキストを修正するのに役立つ設定であることがわかりました。また、DrawingVisual または DrawingContext のガイドライン/スナップ設定のいずれについてもうまくいきませんでした。

この問題は Win7 と Win2008R2 の両方で再現されており、アプリケーションは .NET 4.5 を実行していることに注意してください。

何か案は？

私は独自のグラフ ユーザー コントロールを作成しようとしています。既に win フォームで作業しているものがあり、それを WPF の世界に移動しようとしています。

私は描画の方法を学ぶことから始めているので、最初に、WPF で座標がどのように機能するかを学ぶために、ウィンドウ全体を塗りつぶす黒い楕円を描画しようとしていました。

ここにコードがあります。アプリケーションを実行すると、何も表示されません。何が欠けているのでしょうか?