为什么 CompositionTarget.Rendering 采用 EventArgs 而不是 RenderingEventArgs？
CompositionTarget.Rendering 事件是一个普通的旧式 EventHandler，带有普通的旧式 EventArgs。然而，在现实生活中，它显然总是获得 的实例渲染事件参数。因此，您的事件处理程序必须首先强制转换 EventArgs，以便从中获取有用的信息。
为什么事件不是 EventHandler 类型，这样我们就可以更轻松地获取参数（更重要的是，这样我们甚至可以知道参数在那里）？ 为什么 Microsoft 选择为该事件提供错误的签名？
我想知道向后兼容性 - 是否存在 RenderingEventArgs 尚不存在的版本？ ——但事实似乎并非如此。根据 MSDN 的说法，RenderingEventArgs 和 CompositionTarget 是在两个平台的同一版本中引入的 - 在 WPF 中，两者都是在 .NET 3.0 中添加的；在Silverlight中，两者都是在Silverlight 3.0中添加的。
如果它给出了任何提示，我遇到了一个旧的讨论线程有人说，“委托使用 EventArgs 是因为这样做可以在编组方面带来某种性能提升。”如果有人可以解释这可能会带来什么样的性能胜利，我愿意接受这个答案。
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 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
编组的胜利可能是低级内存管理的事情。由于 EventArgs 是事件最常见的参数形式，因此在插件的低级事件处理实现中可能会预先分配缓冲区。它甚至可能只在某些平台上并且只有在密集渲染的情况下才是胜利。
最新的 SL 版本中的渲染速度得到了显着提高，我怀疑正是这样的调整推动了这一点。
当接口由于实现而受到影响时，这是一种痛苦，但如果胜利是重大的，那么这是一个公平的权衡。此外，在这种情况下，功能并没有真正的损失，因为转换和获取底层数据相当容易。
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.