wpf - CompositionTarget.Rendering が RenderingEventArgs ではなく EventArgs を取るのはなぜですか?

Question

CompositionTarget.Renderingイベントは、単純な古い EventArgs を持つ単純な古い EventHandler です。ただし、実際には、明らかに常にRenderingEventArgsのインスタンスを取得します。したがって、イベント ハンドラーは、EventArgs から有用な情報を取得するために、EventArgs をキャストすることから開始する必要があります。

type のイベントではないのはなぜでしょうか。なぜならEventHandler<RenderingEventArgs>、より簡単に引数に到達できるからです (さらに重要なのは、引数がそこにあることを知ることさえできるからです)。Microsoft がこのイベントに間違った署名を与えることを選択したのはなぜですか?

後方互換性について疑問に思いました.RenderingEventArgsがまだ存在しないリリースはありましたか? ――しかし、そうではないようです。MSDN によると、RenderingEventArgs と CompositionTarget は、両方のプラットフォームの同じリリースで導入されました。WPF では、どちらも .NET 3.0 で追加されました。Silverlight では、どちらも Silverlight 3.0 で追加されました。

何かヒントがあれば、誰かが言った古いディスカッション スレッドに出くわしました。誰かがそれがどのようなパフォーマンスの勝利であるかを説明できるなら、私はそれを答えとして喜んで受け入れます.

Answer 1

マーシャリングの勝利は、おそらく低レベルのメモリ管理の問題です。EventArgs はイベントの引数の最も一般的な形式であるため、プラグインの低レベルのイベント処理実装に事前に割り当てられたバッファーが存在する可能性があります。一部のプラットフォームでは、集中的なレンダリングでのみ勝利することさえあります.

最新のSLバージョンではレンダリング速度が大幅に改善されており、このような調整がこれを推進していると思われます.

実装が原因でインターフェースが損なわれるのは苦痛ですが、勝利が重要な場合は公正なトレードオフです。また、この場合、基になるデータをキャストして取得するのはかなり簡単であるため、機能が実際に失われることはありません。