wpf-shapes-vs-wpf-geometries

WPF Shapes vs. WPF Geometries

2011-01-11

Each of the Shape derived classes (Rectangle, Ellipse, Ploygon, etc) are very useful when you need to incorporate user interactivity in your graphics, as shapes extend UIElement. As you might know, this base class defines numerous mouse-centric events.

<Grid>
  <Ellipse x:Name="myCircle" Height="100" Width="100" Fill="Red" MouseEnter="myCircle_MouseEnter" />
</Grid>

While shapes are very powerful, you must always be aware that they do come with a high memory footprint. When you look at the inheritance chain of Ellipse and contrast that to the WPF Button, they have much of the same infrastructure! Thus, if you were building some sort of application which needed to plot out 1000s of points of data, and you draw these plot points using the Ellipse, it would be just about as much overhead as drawing 1000 Buttons on the window (more or less).

When you need to generate large amounts of graphical data which does not require any user interactivity, one approach is to use "drawings and geometries". Using classes such as DrawingBrush, you can define a (non-interactive) blog of graphical data by specifying a set of geometry objects. Unlike shapes, geometries have no clue how to render themselves, and are little more than light weight containers which define plot points. Once you have configured a DrawingBrush, you can then assign it to any brush-centric property.

This is great, but now if you needed to interact with the geometries, you would need to do so in code, typically by preforming manual hit testing calculations.

A good middle of the road approach is to the the Path class. While Path is also Shape derived type, it defines a Data property, which can (you guessed it) be set to a set of geometries. This is great when you need to define complex graphical data, which still needs to be interactive as a whole unit. In otherwords, you are not interested in interacting with segments of the path, just the final rendered geometry of the path.

The only downside to working with geometries is the large amount of markup required to generate the data. Thankfully, Expression Design will export any graphical image as a set of paths and geometries when you export the image as a *.xaml file.

One more similar summary:

The main differences between Shapes and Drawing Objects are:

* Shapes are Framework Elements. Because of that you can use them in your user interface just like any other control (e.g. Button, TextBox, etc.). They are also derived from Visual. Therefore they now themselves how to render them.

  Freezables that are in read-only state are called "Frozen Freezables".

* Drawing Objects are no Framework Elements! They are Freezables (derived from Freezable). Therefore they can be set into a read-only state. With this you can significantly enhance performance. However, Freezables in ready-only state cannot be modified using animations or data bindings. This leads to the conclusion that you should only "freeze" Freezables if they represent static graphics without changes during runtime.

* Drawing Objects are no Visuals! To display Drawing Objects you need a Framework Element helper object. The following figure shows this relationship.