Warum nimmt CompositionTarget.Rendering anstelle von RenderingEventArgs EventArgs?

Question

Das Ereignis CompositionTarget.Rendering ist ein einfacher alter EventHandler mit einem einfachen alten EventArgs. Im wirklichen Leben bekommt es jedoch anscheinend immer eine Instanz von RenderingEventArgs. Daher muss Ihr Event-Handler mit dem Casting der EventArgs beginnen, um die nützlichen Informationen daraus zu erhalten.

Warum ist nicht das Ereignis vom Typ EventHandler<RenderingEventArgs>, so konnten wir mehr auf die Argumente leicht zu bekommen (und was noch wichtiger ist, so konnten wir auch wissen, dass die Argumente sind dort)? Warum hat Microsoft entschieden, diesem Ereignis die falsche Signatur zu geben?

Ich habe mich über die Rückwärtskompatibilität gewundert - gab es eine Version, in der RenderingEventArgs noch nicht existierte? - Aber das scheint nicht der Fall zu sein. Laut MSDN wurden RenderingEventArgs und CompositionTarget auf beiden Plattformen in derselben Version eingeführt. In WPF wurden beide in .NET 3.0 hinzugefügt. In Silverlight wurden beide in Silverlight 3.0 hinzugefügt.

Wenn es irgendeine Art von Hinweis gibt, lief ich über eine alte discussion thread, wo jemand sagte: "Der Delegat verwendet EventArgs, weil es eine Art Leistung Gewinn beim Marshalling ist, indem Sie das tun." Wenn jemand erklären kann, welche Art von Leistung gewinnen könnte, wäre ich bereit, dies als Antwort zu akzeptieren.

Answer 1

Der Marshalling Win ist möglicherweise eine Low-Level-Speicherverwaltung Sache. Da EventArgs die gebräuchlichste Form des Arguments für ein Ereignis ist, gibt es wahrscheinlich in der Implementierung des Plugins zur Ereignisbehandlung auf niedriger Ebene vorbelegte Puffer. Es kann sogar nur auf einigen Plattformen ein Gewinn sein und nur mit intensivem Rendering.

Rendering-Geschwindigkeit wurde in den neuesten SL-Versionen erheblich verbessert und ich vermute, dass es Verbesserungen wie diese sind, die dies treiben.

Es ist ein Schmerz, wenn die Schnittstelle aufgrund der Implementierung leidet, aber es ist ein fairer Kompromiss, wenn der Gewinn signifikant ist. Auch in diesem Fall gibt es keinen wirklichen Verlust an Funktionalität, da es relativ einfach ist, die zugrunde liegenden Daten zu generieren und zu erhalten.