Why does CompositionTarget.Rendering take EventArgs instead of RenderingEventArgs?

The CompositionTarget.Rendering event is a plain old EventHandler, with a plain old EventArgs. However, in real life, it apparently always gets an instance of RenderingEventArgs. So your event handler has to start 开发者_C百科by casting the EventArgs in order to get the useful information out of them.

Why isn't the event of type EventHandler<RenderingEventArgs>, so we could get to the arguments more easily (and more importantly, so we could even know the arguments are there)? Why would Microsoft have chosen to give this event the wrong signature?

I wondered about backward compatibility -- was there a release where RenderingEventArgs didn't exist yet? -- but that doesn't seem to be the case. According to MSDN, RenderingEventArgs and CompositionTarget were introduced in the same release on both platforms -- in WPF, both were added in .NET 3.0; in Silverlight, both were added in Silverlight 3.0.

If it gives any kind of hint, I ran across an old discussion thread where somebody said, "The delegate is using EventArgs because there's some kind of performance win on marshalling by doing that." If someone can explain what kind of performance win that might be, I'd be willing to accept that as an answer.

The marshalling win is possibly a low level memory management thing. Because EventArgs is the most common form of argument for an event there is likely to be pre-allocated buffers in the low level event handling implementation of the plugin. It may even only be a win on some platforms and only with intensive rendering.

Rendering speed has been significantly improved in the latest SL versions and I suspect that it is tweaks like this that are getting are driving this.

It's a pain when the interface suffers due to the implementation but it's a fair trade off if the win is significant. Also, in this case there is no real loss to functionality as it is fairly easy to cast and get the underlying data.