Nov 12, 2007 at 12:42 PM
Edited Nov 13, 2007 at 8:52 PM
I have just uploaded an initial version of WPF Rendering and presentation layers
It is more like a "proof of concept" project rather than full implementation. E.g. the rendering cache is never cleared…
In general the Rendering Layer is more stable then the Presentation. The rendering project also has corresponding unit tests (naturally, based on GdiRendere unit tests).
When building the solution for the first time it should be rebuilt in order to work correctly (I think it's due to a bug in VS 2005 WPF build task).
The source is provided in a solution with SharpMap revision 260. There is one change to the SharpMap source I made in order to allow layer removal (LayerCollection.Remove) see also
In addition the panning behavior is implemented manually, as I haven’t managed to achive the desired results using the provided standard tool (and even now there is a slight bug when panning).
This version does not use any asynchronous rendering, so the performance is acceptable but not as good as one might expect. The most disappointing point is the huge difference in rendering speed when drawing stoked geometries compared to unstroked. To see it
just set the Outline widths in the example to 0.0 and see how the zooming panning flies. If anyone knows how to improve the stroked rendering performance it would be an invaluable info (nothing found on all the WPF performance articles on the web).
Another important note – I removed the signing from the projects to allow instrumented profiling.
Below are some major design issues I've encountered, and will be more then glad to your remarks regarding them, as well as any other feedback. I'm especially interested whether I understood correctly the extensibility intentions of SharpMap.
One major design consideration is which object to use as the rendering holder ("RenderObject").
At first, I thought that the natural choice was to System.Windows.Media.Drawing as it actually does exactly what's needed from RenderObject. So the straight forward solution was to create the Drawings inside the rendered, freeze them (to allow rendering not
only on the UI thread), cache them, and return them to the presenter. The View then will Show the drawings using DrawDrawing methods and everything seems nice and clean.
This above design introduces however the following problem: the rendering engine of WPF does not support natively scale invariant lines (a known problem, which may be addressed in the WPF version). The result of zooming in a map with scaled lines is not very
appealing (see for example how the selection drawing looks when the map is zoomed in, both in the Forms implementation and in the WPF one). The way to solve it is either apply the ViewTransfrom to the Geometry (and not to the DrawingContext), or apply a reverse
scaling to the Pen. The first solution cannot be applied with stream geometries, and hence was rules out. In any case, this means that the Drawing as a whole cannot be frozen. Since this was the case, it is more memory efficient to hold the (drawing, brush,
pen) triplet in a manually defined structure, and freeze only what can be frozen. In addition the DrawingContext.DrawGeometry is a bit faster than DrawingContext.DrawDrawDrawing. So the RenderObject approach was chosen.
There is still a problem of sharing the same rendered objects across multiple views, since the Pens are scaled by the view. Maybe lazy copying will be the solution to this.
Note also that the same problem applies to rendering symbols and labels.
BindingSupport in ILayerStyleView
Currently this interface enforces the use of TypeDescriptor to support UI binding. I didn't follow this design (the Style property on my implementation just thorows NotImplemnted).
I felt that it is more natural in WPF to use dependency properties, and this is also the better solution in terms of performance (see
View property types
A dilemma I had was which type should return properties of the various views. Whould it be WPF native types or SharpMap "platform independent" types. E.g. should Background be SharpMap.Styles.Brush or System.Windows.Media.Brush. My decision was that whenever
the properties are not domain specific – a brush is a brush outsite the GIS world too – use WPF types, as the WpfPresenter is platform specific by nature. In cases where the property is GIS specific prefer SharpMap types for type safty (e.g. use GeoPoint and
This is great news!
The problem with scaled lines is widely known and I have the same problem with my other application.
There are one little tool: 3D Tools for the Windows Presentation Foundation with a helper class ScreenSpaceLines3D (to draw fixed width lines in a 3D scene).
Bus as I know, there a some known problems, i.e. memory allocation - very strange for .NET-environment - , and speed issues.
And as I know also, the new version of WPF (may be 3.5) will incorporate the most features of 3DTools, also check, if ScreenSpaceLines3D will be on the box in the next release.
ScreenSpaceLines3D was in the September CTP is the class in System.Windows.Media.Media3D but it looks like it was now out of tthe native WPF-core classes.
Nov 24, 2007 at 2:38 PM
Its good to see a WPF render, but I have found a few problems, the pan does not appear to start from where the cursor is, it's impossible to pan the lower part of the screen into the main view.
The zoom seems to always select the required area to the lower part of the screen.
I attempted to load 6 shp files, 6 two of which being over 3Mb, the rendering slows up to the point of being unable to render the image. It is a known problem with WPF having problems with large numbers of objects, but i known it can cope with theses files
using my own shp file render.
The panning bug is solved and a patch can be found here:
Regarding the performance, as mentioned, I didn't put much of an effort with this respect.
It highly depends on how exactly the data will be served to the render, and will the core components of SharpMap provide any caching / updating services. Since these questions are still open I thought to postpone the design / implementation of efficient caching
Codekaizen – any news regarding the vertex buffers etc?
In any case I would be glad to hear any ideas or recommendation regarding performance in general, and caching design in particular
(I'll open a separate discussion with some specific thoughts).
Thank for your feedback.
Have you had any feedback on stroked rendering performance, because I am having similar issue with a WPF application I am writing. This can render an image made up of many polygons, ~10000, at a FrameRate of 64 for Fill only polygons, but drops to FrameRate
15 when stroked.