I am developing a Maps like application using WPF. I have ~10,000 PathGeometry, Shapes added to the canvas. I have added ScaleTransform and TranslateTransform for zooming and panning controls.
The problem I'm facing is, when I zoom or pan, there is slight lag. Is there a way to organize the data so that I handle only the Shapes that are visible?
Any hints on making it more efficient will be helpful and appreciated.
What kind f stuff are you putting on the canvas? If using pathGeometry, are you enclosing them in Path class? If so, Path has FrameworkElement in its superclass hierarchy, which is responsible for massive performance loss.
Take a look at my question here. Although it is about Shape class, but the reason of performance degradation is the same, FrameworkElement.
If you are doing so, the solution is to use PathGeometry instead, and enclose it in DrawingContext of a DrawingVisual using DrawingContext.DrawGeometry() method.
Here are some links that should help.
Path Geometry
DrawingContext.DrawGeometry()
Optimizing Performance: 2D Graphics and Imaging
And draw the shapes yourself, using combination of lines, and other things provided by classes derived from Geometry class (ArcGeometry, PathGeometry etc).
This should help.
If you want the ultimate in performance for immediate drawing in WPF, then check out WriteableBitmapEx. This is an excellent open source library, which I recently contributed to. it provides GDI-like drawing capabilities on WriteableBitmap and is compatible with Windows Phone, WPF and Silverlight. The API is simple, you get blitting, polygons, lines and simple shapes etc... You won't get datatemplates and gradient brushes however.
Related
I'm trying to draw simple map in WPF. I need to draw shapes, text and images. It also should be possible to use mouse to move around and zoom in and out.
Right now, I have combination of Canvas + Geometry + Transforms to draw shapes, but I don't know how to add text and images.
I already tried various combination of Canvas/Grid and Layout/Render transform. Biggest problem is adding text and images, because transformations are in geometries.
If i understand you right, you're currently putting Path objects (with transformed Geometries) into a Canvas. For adding text and images you could easily add TextBlock and Image objects to the same Canvas and apply your transformations to their RenderTransform property.
A completely different approach would be to use WPF low-level rendering, provided by the DrawingVisual class. You may start at WPF Graphics Rendering Overview.
I am working on a Chart Control,
I need to implement the Chart Snapshot feature for capturing a vector based image in high quality of Curves and Texts, in any requested size.
Can anyone suggest me any solution or a pointer to resolve this problem.
Any kind of help in deeply appreciated.
If you have to save your image in a vector format you can using tracing. Potrace is an open source bitmap-to-vector tracer library (but considers that bitmap tracing is imperfect). Also considers that wpf is linked closely with XAML, a vector graphics markup languages, so you may want convert raster graphics to XAML (though Charles Petzold you can't embed a bitmap in a XAML file)
If you need to draw a vector image you can use the Shape element that provides a base class for shape elements, such as Ellipse, Polygon, and Rectangle; and add the shape as Panel child. If you are dealing with thousands of shape I suggest to use the DrawingVisual class, a visual object that can be used to render vector graphics on the screen, and its RenderOpen method.
To zoom you have to work with transformations, in particular ScaleTrasnform and apply the transformation to your panel or to your shapes.
Hope this help.
You can take a look at XamlToy but I have not already try it.
http://xamltoys.codeplex.com/
I am not quite sure about the differences between the classes System.Windows.Media.Drawing and System.Windows.Shapes.Shape. They both expose functionality related to 2D graphics in WPF. When would you choose one in your WPF application, and when would you choose the other?
A Shape inherits from FrameworkElement and is therefore a high level object which provides features such as hit-testing, styling, layout and data binding. In contrast a Drawing does not inherit from FrameworkElemet and doesn't support any of these features. As the documentation mentions a Drawing is useful for lightweight visual objects. If you are creating a complex brush to use to paint areas or a background a DrawingBrush would be very efficient.
Drawings can combine text, video, images and Geometry objects (another light weight class) to create complex but very efficient and fast drawings.
In short a Drawing is a low-level alternative to a Shape.
As for use cases, it depends.
If you have to animate or do any sort of binding you would use Shapes.
If you are creating brushes or complex clip arts/vector graphics you would probably use Drawings.
Also, if you draw things by overriding OnRender you would mostly use Geometries.
A Drawing is also Freezable and can thus be shared among threads (assuming it is frozen).
I'd like to ask if there is any possibility to draw on WPF Canvas with some kind of a Graphics type providing methods like: DrawLine, DrawPath etc.. (as it was in .NET 2).
I know there's a lot of stuff like storyboards etc.. but I'm planning to do all the drawing in code behind and to have just 1 Canvas in WPF without any child elements.
Do you think it is a good idea? will it be smooth ?
I'd like to ask if there is any possibility to draw on WPF Canvas with some kind of a Graphics type providing methods like: DrawLine, DrawPath etc.. (as it was in .NET 2).
Yes, you need to use the DrawingContext class
Do you think it is a good idea? will it be smooth ?
That's hard to tell, depending on your exact needs... If the canvas doesn't have any child items, I think a better solution would be to create a custom control and override the OnRender method. Regarding smoothness, it all depends on how you implement it...
I'm currently creating a MSPaint-like WPF-application and struggling with the implementation of a snappable grid.
The painting of the grid is no problem with a VisualBrush and a Rectangle but the problem is that these lines are then purely for looks and can't be easily changed (for example highlighted when the snapping to a specific line triggered).
My other idea was to have a 2 Canvas solution where 1 Canvas is used for the elements and one Canvas (who is positioned above the other) contains all the grid lines. However I have the feeling that this would mean quite a performance hit.
Are there any other possible ways to implement this kind of functionality?
Efficiency considerations of a two-panel approach vs DrawingContext
I have good news for you: You are wrong about the significant performance hit. Your two-canvas idea is nearly optimal, even if you use individual objects for the grid lines. This is because WPF uses retained-mode rendering: When you create the canvas, everything on it is serialized into a compact structure at native level. This only changes when you change the grid lines in some way, such as changing the grid spacing. At all other times the performance will be indistinguishable from the very fastest possible managed-code methods.
A slight performance increase could be had by using DrawingContext as Nicholas describes.
A simpler and more efficient solution
Perhaps a better way then drawing individual lines on the grid canvas is to use two tiled visual brushes (one horizontal, one vertical) to draw all unhilighted lines, then use Rectangle(s) added in code-behind to hilight the line(s) you are snapping to.
The main advantage of this technique is that your grid can be effectively infinite, so there is no need to calculate the right number of grid lines to draw and then update this every time the window resizes or the zoom changes. You also only have three UIElements involved, plus one more for each grid line that is currently hilighted. It also seems cleaner to me than tracking collections of grid lines.
The reason you want to use two visual brushes is that drawing is more efficient: The brush drawing the vertical lines is stretched to a huge distance (eg double.MaxValue/2) in the vertical direction so the GPU gets only one drawing call per vertical line, the same for the horizontal. Doing a two-way tiling is much less efficient.
Adorner layer
Since you asked about alternatives, another possibility is to use Adorner and AdornerLayer with any of the solutions above rather than stacking your canvas using eg a Grid or containing Canvas. For a Paint-like application this is nice because the adorner layer can be above your graphic layer(s) yet the adorners can still attach to individual items that are being displayed.
You might consider drawing your grid using the DrawingContext inside of OnRender. Drawing this way does not introduce new UIElements into the visual tree, which helps to keep performance up. In some ways, it is similar to what you are currently doing with the VisualBrush, which also does not create new UI elements per copy.
However, since you will actually be individually drawing each line instead of copying the look of a single line, you'll be able to highlight the grid line(s) that participate in snapping without changing the colors of those that do not.
If you are going to go down this route, make sure to have a look into GuidelineSets for positioning your guide lines (more details here), since you'll probably want to have your guide lines snap to the device's pixels so that they draw sharply.