In creating a drawing application or a simulation containing thousands of shapes, it is advised to used classes derived from Visual (like DrawingVisual) instead of classes derived from Shape due to performance degradation.
I want to know how much is the performance degradation and is majority of it due to FrameworkElement class in the hierarchy of derived classes? And what is the threshold beyond which one should decide using Visual instead of Shape? And what are the pros and cons of losing UIElement and FrameworkElement in the chain?
The Drawing derived classes are all much lighter weight since they're basically just rendering primitives. They don't actually do much except define the region in which they'll be drawn.
When you use classes derived from Shape, the objects all have to register for event handling and work as part of the standard layout system, as well as handle all of their own rendering. This doesn't have a huge impact with few objects, but as you add more, the layout passes and event processing really can have a large impact on overall performance.
I want to know how much is the performance degradation and is majority of it due to FrameworkElement class in the hierarchy of derived classes?
Pretty much all of it - the fact that it derives from FrameworkElement means that a Shape has to handle all of the layout, eventing, and rendering, which is the entire reason it's slower.
And what is the threshold beyond which one should decide using Visual instead of Shape? And what are the pros and cons of losing UIElement and FrameworkElement in the chain?
Measure, and see where the threshold is for you... A lot depends on what you're doing, and how you're using these types.
A good resource to get more details is the Drawings and Shapes section of the WPF Performance Optimization page on MSDN.
来源：https://stackoverflow.com/questions/7447802/how-much-is-the-performence-degradation-caused-by-using-shapes-derived-objects-i