I need to write a gauge control in WPF for a project at work. By gauge control, I mean something akin to a traditional car speedometer: a circular face with numbers and ticks around the circumference, and a needle pointing to the current value. Although I could get my employer to purchase a third-party control, or even find a free one somewhere, I’d still like to write it myself, for curiosity’s sake more than anything else.
My first thought was to ‘skin’ an existing control using a template, something like a ProgressBar for example as it has Minimum, Maximum and Value properties. However, I don’t think this will offer me the flexibility that I need.
I’d like to animate the needle that points to the current value, so that when the gauge’s value changes the needle moves from the old value to the new value. I figured the easiest way to do this would be to have some kind of shape or geometry representing the needle, and then apply a RotateTransform of the relevant number of degrees to get the needle to point to the correct value. The animation’s To property would be set to the ‘value degrees’ property via binding.
It seems to me that there are three basic approaches I could take:
Use one custom FrameworkElement to represent the entire gauge
I could derive from FrameworkElement, override its OnRender method, then use the DrawingContext to draw both the gauge face and the needle. This would mean that I could no longer animate the needle directly using a RotateTransform, but would instead have to redraw the entire gauge every time the value changes. This seems inefficient to me, as the gauge face represents the bulk of the drawing code but would change very rarely. However, this approach is the most lightweight in terms of the number of elements used.
Use two custom FrameworkElements, one for the face and one for the needle
I’m currently leaning towards this approach. One element would represent the face, the other the needle. This would allow me to target the needle element with the RotateTransform. The gauge control would then consist of three elements: the face, the needle, and a Panel container to hold both of them (ie. Canvas, Grid, whatever). So three elements instead of one, hence not as lightweight as the first approach.
Use DrawingVisuals to draw the face and needle
I’ve also read about the DrawingVisual class, but I’m a bit confused as to why anyone would use this as opposed to deriving from FrameworkElement and overriding OnRender, given that DrawingVisual must be hosted in a custom FrameworkElement anyway. It would seem that this approach doesn’t offer any advantages over the second approach, and would require more code, but maybe I’m missing something.
Any thoughts or advice regarding which approach people think is best and why would be most welcome!
Personally I'd recommend making a CustomControl using the second approach. Unless you are going to be showing more than 1000 of the gauges in view at the same time you aren't going to notice the extra element in your visual tree and I think you'll find it's much easier to make and maintain.
You could just style a slider control and feed values into it. You should be able to make a slider look like any kind of gauge you need.
Related
We have a control which we do our own custom drawing in OnRender. However, we would like to use a PNG with transparency as sort of a stencil for various drawing 'passes' if you will.
Now we already know that we can simply use a PNG in an ImageBrush and set it as the control's OpacityMask, but we actually want to do several drawing passes with several different stencils. If we wanted to go the OpacityMask route, we'd have to create separate controls, separate ImageMasks, then stack them all up on top of each other which also clutters up your visual tree.
We don't want to do that. We want to do all of the drawing in the OnRender override of a single Control subclass. We just want those draw calls to be masked out by an image. We then want to repeat that over and over until our drawing is done.
Any way this can be done?
HA! Found it! Odd that the S/O community has been so quiet on this one, but for those looking for it, it's called DrawingContext.PushOpacityMask (and the corresponding 'Pop()') and does exactly what you think it does... it pushes an opacity mask (via a brush) onto the DC and all subsequent drawing is relative to the brush's opacity values.
You can also layer 'masks' for some pretty cool effects too. They are additive, not just the last one set.
I'm pretty sure the built-in OpacityMask is just used with this function in the OnRender call. What this means is you can still use the OpacityMask (provided you push that on first) then your own mask(s) for your own drawing calls. Pretty neat stuff!
Hope this helps others who were looking for this.
I have a WPF application with many tabs..
in one tab.. i make a verycomplex vector drawing consisting of thousands of drawing visuals.. (this represents a machine and all elements need to be interactable..)
It takes 3/4 seconds for drawing this for the first time..After the first draw it should be done..
The problem is if i switch to another tab and comeback, it takes atlease 2,3 seconds to show the tabpage with drawing again.. Since there is no redraw, why should it take so much time..?
If the component is not going to change, you could call Freeze() on it to mark it as done. Without trying it out I don't know if that would help, but you could give it a shot.
Not all objects are Freezable. Check out the MSDN documentation for more info:
http://msdn.microsoft.com/en-us/library/ms750509.aspx
Another thing you could try would be rendering the vector art to a bitmap, and displaying that. Maybe it makes you feel icky to lose the vector precision, but if you know it's not going to change and it will look the same, what's the harm? (If you support printing or something that will require a hi-res version, you could always switch back for that operation.) For info on how to convert a UIElement to a bitmap, check out:
http://msdn.microsoft.com/en-us/library/system.windows.media.imaging.rendertargetbitmap.aspx
Another possible solution: You don't really explain what kind of interaction you are doing with the elements, but if all you want to do is zoom and pan, a RenderTransform may be good enough (which is more efficient than a LayoutTransform and/or moving all the elements individually). I haven't played around with combining Freeze() and a RenderTransform, but you may be able to get the desired zooming while reducing the amount of layout WPF has to do.
I need to render the value of the width or height of a 2d geometry object and the request is for it to not just be text, but somewhat like a dimension that would be a set of building plans. Something like this image...oops too new to post images...like this image that I googled -
http://www.archidigm.com/lounge/archdim/centerline_dim_1.gif
I have looked for something like this, but haven't been lucky in my search. I am fine with creating it, but thought that I would try to not reinvent the wheel if possible. Anyone know of a control or library out there that renders something like this?
This article looks really helpful: http://msdn.microsoft.com/en-us/library/bb613591.aspx. Although it talks about optimizing drawing, it gives mention to a lot of different classes you can use.
Specifically, take a look at the Drawing class: http://msdn.microsoft.com/en-us/library/system.windows.media.drawing.aspx#snippetGroup1
If you want the shapes to be interactive (because it seems like you are building a CAD-like application), the DrawingGroup might help. Check out this example: http://msdn.microsoft.com/en-us/library/system.windows.media.drawinggroup.aspx#snippetGroup
Also, DrawingGroup might be a good way to group the actual shape (for example, a wall in a building) and the ruler object that shows the dimensions.
What is the best approach to render charts and then save them on a hard drive for further distribution using WPF?
I found a number of ways to accomplish this by using the following types:
DrawingVisual - creating a object of this type and then rendering graphics on its context;
Shape - deriving from the Shape class and then overriding its DefiningGeometry property where the actual rendering is happening;
PathFigure - adding LineSegment-s to an instance of this class and then adding this instance to a Canvas;
Adorner - deriving from it and then overriding its OnRender method;
WritableBitmap - rendering on it and then adding the bitmap to a Canvas.
Of course I'm going to write an app to test how fast each of these will be. But can anybody tell me:
whether am I on the right track?
are there any other means to do such rendering?
which one of them is the best in
terms of performance?
It all depends on your actual usage, in your case you mention saving on the hard drive for "further distribution" - I'm going to assume you are saving them as an image (jpg or png) and not as wpf objects (xaml).
You should consider if WPF is the right tool for the job, WPF is a UI framework and not a generic image processing library, it may be best to use something else entirely for generating images.
For a reasonable number of points your performance bottleneck will be encoding the image and saving it to disk - not actually rendering it - so you should choose the method that is easier for you to code.
All the articles about high performance WPF charts are a: about charts with 10,000 points and more (because that is where the performance problems are), b: about charts you display in your GUI (because otherwise you can use an image processing library to create the bitmap) and c: charts that change all the time (so they work nicely with data binding) - there's a reason why they don't talk about saving charts to disk.
For a very large number of points:
The fastest way to draw in WPF is to inherit from FrameworkElement (not Adorner) and override OnRender.
When the data changes often it is recommended to use multiple DrawingVisual objects because then you don't have to re-render everything when one value change - but this is not relevant for you since the image won't change after you save it anyway.
WritableBitmap is used for raw bitmap access, you use it when you decide to give up on all the nice layout and drawing WPF gives you because you can't take the overhead, if this is the case you should re-read my first point above.
So, to summarize, you are asking the wrong question :-) if you need to save images to disk than either the WPF rendering speed is not your bottleneck or you shouldn't be using WPF to begin with. If you do use WPF just pick whatever is easiest for you to code.
BTW: Adorners are used to display "floating" elements above the normal UI, you can use them for tooltip-like features but not for the main chart rendering (and you probably don't want them at all since your main usage is saving the image to disk), FrameworkElement is the base class you are looking for.
I always use a Canvas when I'm laying out my visuals usually because I will need adjust the RenderTransform.TranslateTransform to animate in some way. A colleague recently told me that unless I explicitly need to animate I should always use the A Stackpanel because it is faster than a RenderTransform.TranslateTransform when laying out objects to the visual.
Is this true?
Anyone have any data either way?
I don't have any data on this, but if we're just talking about stacking then you using a TranslateTransform to achieve the exact positioning of each item seems extremely fragile since the item could theoretically be of different heights/widths which could also theoretically change dynamically at runtime not to mention if the designer changes them by hand they have to redo the translate transform for N other UI elements. Using StackPanel means the Measure/Arrange phases will occur and no matter what size the items are they will be laid out precisely.