Почему CompositionTarget.Rendering принимает EventArgs вместо RenderingEventArgs?

Question

Событие CompositionTarget.Rendering представляет собой обычный старый EventHandler с простыми старыми EventArgs. Однако в реальной жизни он, по-видимому, всегда получает экземпляр RenderingEventArgs . Поэтому ваш обработчик событий должен начать с приведения EventArgs, чтобы получить из них полезную информацию.

Почему не событие типа EventHandler<RenderingEventArgs>, поэтому мы могли бы легче получить аргументы (и что более важно, чтобы мы могли даже знать, что аргументы там) ? Почему Microsoft решила присвоить этому событию неправильную подпись?

Я задавался вопросом о обратной совместимости - был ли релиз, в котором RenderingEventArgs еще не существовало? - но это не так. Согласно MSDN, RenderingEventArgs и CompositionTarget были представлены в одном выпуске на обеих платформах - в WPF обе были добавлены в .NET 3.0; в Silverlight оба были добавлены в Silverlight 3.0.

Если это дает какую-то подсказку, я наткнулся на старую дискуссионную ветку , где кто-то сказал: «Делегат использует EventArgs, потому что при этом происходит какая-то выигрыш в производительности при маршаллинге». Если кто-то может объяснить, какой это может быть выигрыш в производительности, я бы с готовностью принял это как ответ.

Answer 1

Маршаллинговая победа - это, возможно, низкоуровневое управление памятью.Поскольку EventArgs является наиболее распространенной формой аргумента для события, вероятно, в реализации плагина для низкоуровневой обработки событий есть предопределенные буферы.Это может быть даже победой на некоторых платформах и только при интенсивном рендеринге.

Скорость рендеринга была значительно улучшена в последних версиях SL, и я подозреваю, что такие твики приводят в движение.1003 *

Это боль, когда интерфейс страдает из-за реализации, но это справедливый компромисс, если выигрыш значителен.Кроме того, в этом случае нет реальной потери функциональности, так как довольно легко привести и получить базовые данные.