Probably a bad title but I am working on a winforms app and it was all going well until I started doing usability testing at different sizes.
I noticed that the "redraw" of controls on a resize event would go VERY slow. I googled and found that splitcontainers and dockstyle fill don't play well so I changed my approach and the performance improved but it was still slow.
It turns out my background images on my usercontrols was causing the delay and it got me wondering what's best practice for this? I have a few different gradients that are around 1024x768 that are set to sizemode stretch.
My temporary fix is to replace my pretty gradient background with solid black. But that does not make things look as nice. It seems that if I had two different sized background images and swapped them on form_resize that would be most efficient but there is a lot of times where I do things the hard way because I don't know better. So I figured i'd ask here. This is specific to just winforms. I export vector when I can for my wpf/sl stuff.
Is the gradient image very specific? If it's just a linear gradient can't you paint the background yourself?
In the user control, add an OnPaint override like so:
protected override void OnPaint(PaintEventArgs e)
{
Brush brush = new LinearGradientBrush(
Point.Empty,
new Point(0, this.Height),
Color.Yellow,
Color.Green);
e.Graphics.FillRectangle(
brush, e.ClipRectangle);
}
Try to set the BackgroundImageLayout Property to 'None' on your controls with the gradients. This usually gives a moderate performance boost
Related
Other questions on SE address how to speed up nested UI control resizing, but- what if there aren't any controls?
As you drag the edge of a WPF window, even a main window with no content, black bars flicker briefly during the drag. This produces a crummy feel- one that I don't want to inflict on customers:
It does get slower and heavier with a full UI on top of it as well. This doesn't even get into how ugly it looks when resizing using the top or left edges. Windows Forms- even with the heaviest UI I've built- never looks this bad right off the bat.
What can be done to make WPF window resizing performance comparable to win forms?
(I have Windows 7 x64 and a triple monitor system on an AT Radeon HD 7470.)
You could update your graphic card and try it out again but that wont change anything. The reason is pretty simple. We all get to see this sometimes based how fast/slow our computer is. Sometimes it runs smooth because we do not have many visuals to draw. The reason is no proper background color is found in graphic card at that moment in redrawing process. Your drivers are fine, and its not just because you use Wpf. Other techniques use the same mechanism behind redrawing.
The first thing WPF will do is clear out the dirty region that is going to redraw. The purpose of dirty regions is to reduce the amount of pixels sent to the output merger stage of the GPU pipeline. Here is where we see the black color. Window itself at that point has no background color or its background color is set to transparent and so to us the GPU draws the black background. Things run async in wpf which is good so.
To fix this you could set a fix color such as "White" to the Window. Then the WPF system will clean out the dirty region but fill it automatically with white color instead of black. This usually helps.
Match the window color or the color of top most layer. Dont let GPU use black and you should do fine. Btw Wpf is faster than WinForm so dont worry.
The look is crummy indeed, especially when using the top or left border.
Which exact problem your screen shot is showing depends on how long your app is taking to render as well as a couple of background related settings that you might be able to tweak to get better resize. Plus part of the ugly resize is specific to Aero.
While I can't address the specific crazy slowness of WPF redraw, I can at least give some insight on why you see black, where that is coming from, and whether you can change to a less annoying fill-in color.
It turns out there are multiple different sources of the black and the bad resize behavior from different Windows versions that combine together. Please see this Q&A which explains what is going on and provides advice for what to do (again, not specific to making WPF faster but just seeing what you can do given the speed you have):
How to smooth ugly jitter/flicker/jumping when resizing windows, especially dragging left/top border (Win 7-10; bg, bitblt and DWM)?
this is my fist question here,
but I didn't find a real answer to my question.
I work on a visualization program and use C# and WPF.
I need to draw a treemap. I actually create Rectangle objects and then add them to the Canvas which works really nice and is very useful, since I also add event handlers to those rectangles (mouse click).
I have a problem with the performance though.
When I add the rectangles and set the Stroke property (SolidColorBrush) the whole process is slowing down extremely. Without those strokes set the speed is ok.
I already improved the performance a little by adding Rectangle objects to a newly created Canvas object and then adding this new Canvas object to the original Canvas object (so not all rectangles are direkt children of the original Canvas, which should help speeding things up).
So my question is how it is possible to add a Stroke to all those Rectangles without breaking the speed.
You can find a comparison of the 'strokeless' and 'stroked' treemap versions in the links.
Treemap without Strokes
Treemap with Strokes
Thank you very much for your help!
edit:
Ok, I have found a solution!
Sorry for writing here first, but I already searched for hours to find a solution but now I found out tht the problem was my used SolidColorBrush!
I have something like this:
public static SolidColorBrush TreeMapBorderBrush;
And I use this Brush to set the Stroke property of every Rectangle that should be added to the Canvas. But exactly that was the problem.
The code looked like this before:
rect.Stroke = Visualization_Helper.TreeMapBorderBrush;
I changed it to this now:
rect.Stroke = Visualization_Helper.TreeMapBorderBrush.Clone();
So I only work with a copy of that Brush on each Rectangle now, which speeds up the processing like there was no Stroke (like in my question)!
Just for your information! Weird!
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.
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 working on SEM image processing application, written in WPF. I have an image display control, derived from Canvas, which displays image & overlays using DrawingVisuals (one for each "layer"). It also implements Zoom & Pan using scale & translate transform, applied on DrawingVisuals.
When I zoom in the image to see individual pixels, they are displayed smooth, evidently using bilinear filtering to stretch the bitmap (no surprise, as WPF is rendered through Direct3D). However, for my use case, I would rather see individual pixels as sharp boxes, as usual in any image editor like Photoshop. That's why user of my app zooms the image -> to be able to operate on pixel level.
Is there such option in WPF (other than manually stretching the bitmap before displaying it)? I was not able to find anything.
thanks in advance,
Zbynek Vrastil
Czech Republic
Finally found an answer, with some help from Experts Exchange. Class RenderOptions defines attached property BitmapScalingMode, which can be set to NearestNeighbor. So,
RenderOptions.SetBitmapScalingMode(imageDisplay, BitmapScalingMode.NearestNeighbor);
does the trick.
Zbynek Vrastil
Hate to put a dampener on things, but if NearestNeighbor works like GDI+, then this will give you a limited success. As you increase magnification in areas of high contrast you might not get the desired results. In GDI+ you find blacks becoming blue, and whites becoming red - again I stress in areas of high contrast! If this isn't the case in WPF, think yourself lucky!
Perhaps a WCF developer could confirm that?
I've found that there are more options to consider, but I can only speak for the GDI+ Graphics class, which might be useful to someone.
Graphics graph = e.Graphics;
graph.InterpolationMode = InterpolationMode.NearestNeighbor;
graph.CompositingQuality = CompositingQuality.AssumeLinear;
graph.SmoothingMode = SmoothingMode.None;
This works for me. I think the SmoothingMode is the trick. Hope this helps someone else out there.