Winforms: How to speed up Invalidate()?

Question

I'm developing a retained mode drawing application in GDI+. The application can draw simple shapes to a canvas and perform basic editing. The math that does this is optimized to the last byte and is not an issue. I'm drawing on a panel that is using the built-in Controlstyles.DoubleBuffer.

Now, my problem arises if I run my app maximized on a big monitor (HD in my case). If I try to draw a line from one corner of the (big) canvas to the diagonally oposite other, it will start to lag and the CPU goes high up.

Each graphical object in my app has a boundingbox. Thus, when I invalidate the boundingbox of a line that goes from one corner of the maximized app to the oposite diagonal one, that boundingbox is virtually as big as the canvas. When a user is drawing a line, this invalidation of the boundingbox thus happens on the mousemove event, and there is a clear lag visible. This lag also exists if the line is the only object on the canvas.

I've tried to optimize this in many ways. If I draw a shorter line, the CPU and the lag goes down. If I remove the Invalidate() and keep all other code, the app is quick. If I use a Region (that only spans the figure) to invalidate instead of the boundingbox, it is just as slow. If I split the boundingbox into a range of smaller boxes that lie back to back, thus reducing the invalidation area, no visible performance gain can be seen.

Thus I'm at a loss here. How can I speed up the invalidation?

On a side note, both Paint.Net and Mspaint suffers from the same shortcommings. Word and PowerPoint however, seem to be able to paint a line as described above with no lag and no CPU load at all. Thus it's possible to achieve the desired results, the question is how?

Answer 1

To clarify: Is the user drawing a straight line, or is your line actually a bunch of line segments connecting mouse points? If the line is a straight line from the origin to the current mouse point, don't Invalidate() and instead use an XOR brush to draw an undoable line, and then undraw the previous line, only Invalidating when the user is done drawing.

If you're drawing a bunch of little line segments, just invalidate the bounding box of the most recent segment.

Answer 2

How about having a different thread that "post updates" to the real canvas.

Image paintImage;
private readonly object paintObject = new object();
public _ctor() { paintImage = new Image(); }

override OnPaint(PaintEventArgs pea) {
    if (needUpdate) {
        new Thread(updateImage).Start();
    }
    lock(paintObject) {
        pea.DrawImage(image, 0, 0, Width, Height);
    }
}

public void updateImage() {
    // don't draw to paintImage directly (it might cause threading issues)
    Image img = new Image();
    using (Graphics g = img.GetGraphics()) {
        foreach (PaintableObject po in renderObjects) {
            g.DrawObject(po);
        }
    }
    lock(paintObject){
        using (Graphics g = paintImage.GetGraphics()) {
            g.DrawImage(img, 0, 0, g.Width, g.Height);
        }
    }
    needUpdate = false;
}

Just an idea, so I haven't tested the code ;-)

Answer 3

For basic display items like lines, you should consider breaking them up into a few parts if you absolutely must invalidate their entire bounds per drawing cycle.

The reason for this is that GDI+ (as well as GDI itself) invalidates areas in rectangular shapes, just as you specify with your bounding box. You can verify this for yourself by testing some horizontal and vertical lines versus lines where the slope is similar to the aspect of your display area.

So, let's say your canvas is 640x480. If you draw a line from 0,0 to 639,479; Invalidate() will invalidate the entire region from 0,0 to 639,0 at the top down to 0,479 to 639,479 at the bottom. A horizontal line from, say, 0,100 to 639,100 results in a rectangle only 1 pixel high.

Regions will have the very same problem because regions are treated as sets of horizontal extents grouped together. So for a large diagonal line going from one corner to the other, in order to match the bounding box you have setup- a region would have to specify either every set of pixels on each vertical line or the entire bounding box.

So as a solution, if you have a very large line, break it into quarters or eighths and performance should increase considerably. Revisting the example above, if you just divide in half for two parts- you will reduce the total invalidated area to 0,0 x 319,239 plus 320,240 x 639,479.

Here is a visual example of a quarter splits. The pink area is what is invalidated. Unfortunately SO won't let me post images or more than 1 link, but this should be enough to explain everything.

(Line Split in Quarters, Total Invalidated Area is 1/4 of the surface)

a 640x480 extent with 4 equal sized boxes carved behind a line drawn across the diagonal

Or, instead of specifying a bounding box, you may want to consider rewriting your updates so that you only draw the portions of items that match the region that must be updated. It really depends on how many objects need to participate in a drawn update. If you have thousands of objects in a given frame, you might consider just ignoring all the invalidated areas and just redraw the entire scene.

Answer 4

If you have used regions properly, as you described then it should work fast enough. It means that your problem is caused by some circumstances or bugs that you did not describe. Please do the following:

Create the smallest code that shows the problem.

This should always be the second step during debugging, if you are not able to find the answer in several minutes. If you are not able to reproduce your problem with smaller implementation it simply means that it is caused by some of your bugs that have not been described here. Otherwise we can help.

Answer 5

I've tried many different approaches now and have not yet reached a conclusion. To try to isolate the problem I made a small test application and it can be downloaded here. This "Benchmarker" application will draw a single line from the mousedown location to the mouseup location (don't pay attention to the fact that it doesn't clean up the canvas properly, it doesn't matter), and if the line is drawn from corner to corner diagonally across a big screen and the mouse is moved around a lot, there is a small visible lag. The CPU also goes up to about 50%. The BitBlt version doesn't blit properly, but that doesn't matter either. In this case I invalidate the (whole) canvas using a 40ms timer and this seems to be even slower than using the native .Net methods.

So, at this point I'm proposing that invalidating a full HD canvas flawlessly can't be done with Windows Forms. I'm interested in any counteropinions.

Have any of you guys out there had any experience with i.e. DirectDraw? Could an alternative solution involve to manually update a drawing surface using DirectDraw or DirectX? Would this be quicker, even if that surface was still inside a Windows Form?

Thanks for all answers so far. I believe this is a topic that has affected many of us from time to time.

• Peder -

Answer 6

You can't really speed up Invalidate. The reason why it is slow is because it posts a WM_PAINT event onto the message queue. That then gets filtered down and eventually your OnPaint even is called. What you need to do is paint directly in your control during the MouseMove event.

In any control I do that requires some measure of fluid animation my OnPaint event generally only calls a PaintMe function. That way I can use that function to redraw the control at anytime.

Answer 7

Since this is a fairly popular thread, the following link is a pretty interesting discussion about how to speed up GDI+ in general:

http://www.gamedev.net/community/forums/topic.asp?topic_id=467752