We Keep Coding

"flickering" pictureboxes due to being drawn while being moved

I am creating a program where users are able to use a GUI to create configuration files that bind commands to certain keys for a different unrelated program. In this program, I have a checkbox that allows the user to chose to use the DVORAK layout or the QWERTY layout. I have PictureBox-es being used for the image of each key. When the user checks the checkbox for the DVORAK layout, the program rearranges these pictureboxes so that they are now in the DVORAK layout instead of the QWERTY format. When this happens, about 90% of the time a few of the keys are drawn before they have moved, leaving 1 frame where there are keys overlapping or missing keys, causing a sort of "flicker".
I was wondering if there is any way to wait until right after the form's draw call has finished and then rearrange the keys to give the maximum possible amount of time for them to rearrange. I would need to be able to know the time until the next draw call (or if there is a constant amount of time inbetween every draw call, the time since the last draw call would also work) wait that amount of time, and then rearrange the pictureboxes.
Thank you for any and all help!

I had a similar problem with TreeViews. And, like TreeViews, PictureBox doesn't have a DoubleBuffered property. So I made a new control, using TreeView as the base.
Here's a PictureBox version of that class:
public class PictureBoxNoFlicker : PictureBox {
public PictureBoxNoFlicker() {
this.SetStyle(ControlStyles.DoubleBuffer, true);
this.SetStyle(ControlStyles.UserPaint, true);
this.SetStyle(ControlStyles.AllPaintingInWmPaint, true);
}
}
This code replicates double-buffering. Simply use this control instead of the standard PictureBox.
Unfortunately, I can't reproduce your problem, so I am taking a bit of a punt and hoping this resolves your issue.

More than 2 millions rectangles in a WPF canvas

I am creating a custom control for semiconductor wafermap
Each of those small rectangle need to satisfy following requirements;
1) Tooltip to show the index
2) clickable to include or exclude from the wafermap definition.
no of dies in the wafermap may cross 2 millions in the case of 1400 x 1450 dies.
at certain point i need to show all the dies in a window (most of the clicking will happen in zoomed view).
Currently I am adding each die separately using Rectangle shape and store the coordinate information (index like (10,10)) for the tooltip as an attached property.
I use different style to each die; depending on certain calculation and position of the die.
DieStyle1 = new Style { TargetType = typeof(Rectangle) };
DieStyle1.Setters.Add(new Setter(Shape.FillProperty, Brushes.MediumSlateBlue));
DieStyle1.Setters.Add(new Setter(Shape.StrokeProperty, Brushes.White));
DieStyle1.Setters.Add(new EventSetter(MouseDownEvent, new MouseButtonEventHandler(DieStyle1_MouseDown)));
this approach is slow and use high memory too. so suggest a better way to achieve this in WPF?

In creating a designer for christmas tree lights, I ran into the same problem. Using UIElement or Shapes is way too slow when you get to 100+ items. The best approach to handle a very large number of items entails using double-buffering with your own managed buffer of the image and a structure to handle the clicks. I have posted my project which should give you a good start. It can be obtained at:
http://sourceforge.net/projects/xlightsdesigner/
You are interested in the Controls\ChannelitemsCanvas.cs. It can be modified to suit your needs and uses a quad-tree to store the rectangles so that click events can be quickly determined.

High performance plot control in WPF

I am doing some work for which I need to develop a control, it should be a simple graph that shows several points and two edges.
My problem is that I need to show up to 16k points, with an update rate of 30 Hz. Has anyone done something similar?, and has any advice?.
For example whether to inherit from FrameworkElement or Control (ItemsControl in this case). If the control inherits from FrameworkElememt it may have a better performance drawing the points in the OnRender method but I would miss the Templating feature that comes from inheriting from Control.
Or does there exist another control that can do this out there?
Thanks in advance for your time.

I ended up using InteropBitmap, it is the fatest bitmap rendering class from WPF.
It allows you to map the image that you want to paint (in memory) and then reder it as a Image. This was perfect as i needed to plot points on the screen.
I got great performance (almost 50Hz for 20k points), i also use PLINQ to update the points in memory.
check this article for more details...

Try and read about ZoomableCanvas. I believe it can solve your problem. You can render all the points as small rectangles/ellipses inside the ZoomableCanvas.

WPF canvas performance- children.add called many times

I'm drawing a lot of lines on a long canvas (think stripchart) and have it tuned fairly well for performance, using the low-level geometry classes and freezing them, etc. This improved performance dramatically, but it still takes a few seconds to load a few thousand items into the canvas. I ran a performance analysis on the application, and it looks like a big percentage of the time is taken by each call to canvas.children.add(). I've read that this should be a lightweight call, and since I'm calling it numerous times in one method, it shouldn't be trying to do anything heavy inbetween... Could there possibly be any other reason this might be taking so much time? And any way I might speed it up?
The performance is not terrible, but I fear it could become more of a problem later when I need to deal with larger sets of data.
Just for reference, it looks like it is called 1400 times in this sample, and it taking almost 3 seconds of CPU time on a modern/fast laptop.
The canvas is contained in a hierachy of other controls though, so I'm curious if they might be contributing to this.
Extra note: I'm also not setting a specific height on the canvas, as it is set to fill the grid parent container. Could this be a source of the problems?

Main problem is that Children.Add is always a slow operation, even if you use StreamGeometry objects. I faced the same problem recently and concluded the following:
If you put a bunch of objects into a new canvas and nest it into the main canvas, the performance of the addition operation will be increased dramatically.
So, instead of adding 1400 elements, put 200 elements in 7 canvases and add those 7 canvases to the main canvas.
Since all objects now belong to different canvases, you will need to adjust your app a bit, but this would be a less drastical solution than moving to an alternative solution like DrawingVisual

Just to add about the hierarchy of controls the canvas is within, and the height of the canvas:
the Canvas always takes as much space as its given, and no matter what children u add to it - it NEVER triggers a new Measuer/Arrange passes on its parents. therefor whatever u do inside a canvas could never affect the visual tree it is contained in.
To sum it up - the problem cannot come from there, and the suggestion about the StreamGeomatry is exactly right- this is what causing u the performance issues, and switching to streamgeormatry would solve it.

I would suggest that you draw your shapes directly into an image instead of adding them as children.
Rendering children has a HUGE overhead (as you can see).
There's a similar question with a reference to some helpful articles:
How to draw line of ten thousands of points with WPF within 0.5 second?

Windows Form Ordering using MDILayout

I have a very specific problem using C# and a Windows MDI Form application. I want to display two (or more) images to the user, a 'left' and a 'right' image. The names of the images are concealed from the user, and then the user selects which image they prefer (this is part of a study involving medical image quality, so the user has to be blinded from possibly relevant capture parameters which might be revealed in the image name). Instead of showing the actual names, substitute names like 'image 0' and 'image 1' (etc) are shown to the user.
Whenever I use the standard MDILayout.TileVertical or TileHorizontal, the images are loaded in reverse order. For example, if I have image 0 and image 1, they are displayed
Image 1 Image 0
Three or more images would be something like
2 1 0
or
3 2
1 0
And so forth. The problem is, my users are confused by this right to leftness, and if I have another dialog box that asks them which image is better (or to rate the displayed images), they always confuse the order of images on the screen with the order of images in the dialog box. That is, if I just order the images 0 1 2 3 etc in a ratings dialog, they assume that image 3 as it's displayed is image 0 in the MDI parent window, image 2 is image 1, etc-- they read left to right, and the images are being displayed right to left. If I reorder the tabs in the ratings dialog box to reflect the order on the screen, that just confuses them further ("Why is image 3 before image 2?") and the results come out in the wrong order, and are generally unusable.
So, how do I force the ordering of displayed windows using MDILayout in C#? Do I have to do it by hand, or is there some switch I can send to the layout manager?
Thanks!

Why are you using an MDI interface? Surely a single window with a TableLayoutPanel or similar providing layout would be more suitable. The only reason you'd want to use a MDI layout is to allow the users to move the windows, which as far as I can tell from your description of the problem isn't desirable anyway?

Another idea would be to put the actual rating mechanism at the bottom of each child window. So the answer is actually attached to the picture on their child windows instead of having the answers in their own area.

Could you avoid this problem by (before displaying the images) you:
Put the image references in a structure (array or similar).
Have a recursive function build a reverse order structure (or reorder the original).
Use the new reversed order structure to build your child windows as before.
It would add one more layer but might solve your problem if no one finds the reverse layout order switch soon enough.

I strongly recommend following Groky's advice and using a single-form interface rather than MDI for this.
If you must use MDI, you need to know that the MDI layout methods use the Z-order of MDI forms to determine where the forms end up. For example, if image 2 is behind image 1, then image 1 will be on the left and image 2 will be on the right. The most logical way to cause this to happen would be to load image 2's form, then image 1's form, then do the MDI layout. You can also use the ActivateMdiChild method to put the forms in a particular order (activating one form puts the other forms behind it).
It's complicated and error-prone, and I strongly recommend having a two-pane interface on a single form instead, but this will work.

Thanks Owen and Groky, but the Single-Form interface is just not going to work. First, I already have the display code in the MDI format, so that rewrite would require a very, very large rewrite of the code. It took me about three weeks to write the basics of the app a while ago; these aren't jpgs I'm showing here, these are DCM images, and each one is a good 30 mb, with a variety of support tools that I haven't seen outside of medical imaging.
Second, some radiologists don't like split screening for image comparison, and others require it. As such, to accommodate both kinds of users, I set this up with tiling, but then the user can maximize images and then switch between them. So, MDI is the right approach for that differing set of tastes; a single interface with a very complicated set of tab controls just sounds like a nightmare compared to an already extant and (for the most part) working system.
However, since I do control the way in which images are displayed, I can force the z-ordering, and then that should work, right? That's the basis of Fred and Owen's answers, if I'm reading them properly. The user enters 'evaluation mode', and then the program loads the images, shows them, and only once the user has entered an evaluation are the images closed. Given that constraint, I can probably enforce a particular z ordering (maybe by looping from length to 0 rather than from 0 to length).