3

I'm currently working on the user interface of a win forms application. The primary window is a borderless form whose surface area is almost entirely rendered in the Form.Paint event. A back buffer is created and it's drawn fairly conventionally:

private void form_Paint(object sender, PaintEventArgs e) {
  e.Graphics.DrawImage(BackBuffer, e.ClipRectangle, e.ClipRectangle, GraphicsUnit.Pixel);
}

Certain regions of the back buffer get redrawn under various conditions; mouse-over effects are quite common. The class which does redrawing carefully invalidates only applicable areas. In spite of this, simply swiping the mouse across the form is enough to crank a high-end CPU to > 50% usage for several seconds.

I've profiled the application and well over 80% of the CPU time is being burnt on the call to DrawImage above. I knew that GDI+ is slow and employs no (little?) use of GPU... and the target platform for the application makes no guarantee that the GPU wont be integrated in the first place. But I had no idea that it was this bad.

Should I face the fact that GDI+ is just not fast enough for what we wish to do, or is there an opportunity for improvement in the code, still?

-edit-

BackBuffer represents a bitmap which is created during system startup. Its size matches the screen resolution. Various regions are drawn on it during a variety of events such as mouse overs and clicks. It is created rather simply:

this.BufferBmp = new Bitmap(screenWidth, screenHeight);
this.Gfx = Graphics.FromImage(BufferBmp);

Gfx.TextRenderingHint = System.Drawing.Text.TextRenderingHint.AntiAliasGridFit;
Jesse Hallam
  • 6,794
  • 8
  • 48
  • 70
  • How often are you calling that method, and how large are the clip rectangles? I suspect that you're blitting from the back buffer to the screen more often than you have to. – Jim Mischel Nov 10 '10 at 19:43

3 Answers3

3

GDI+ can be very nicely performant if you treat it right. I would suggest profiling the drawing code with something like RedGate's Ants but there are several other rules of thumb you can look at to increase performance:

  • Use the Graphics object passed in the OnDraw event, don't create your own
  • Use clipping regions to minimize the area that needs to be redrawn
  • Create drawing objects such as Brushes, Fonts and Pens at class scope (don't recreate each time)
  • Avoid having too many method calls originating from the OnDraw method
  • Avoid too much object creation during the drawing phase
  • Try/catch blocks will impact performance
  • Could use GDI instead of GDI+ (see link below)

Also, there is an option to do BitBlt instead. See here for a similar question and solution.

Community
  • 1
  • 1
Paul Sasik
  • 79,492
  • 20
  • 149
  • 189
  • Hi Paul. I did use ANTS. It identified the bottleneck occurring at the e.Graphics.DrawImage location in the code. To my great surprise, none of the hit testing (done inelegantly with Rectangle.Intersect) or back buffer drawing is causing any significant load. – Jesse Hallam Nov 10 '10 at 19:42
  • @Kivin: Interesting. What exactlyu is DrawImage drawing? Is it cached or created on the fly? – Paul Sasik Nov 10 '10 at 19:45
  • BackBuffer is a class which contains a Bitmap - created on startup - which matches the screen resolution. It is responsible for drawing the appropriate surfaces during a variety of events, such as mouse overs and clicks. It implicitly converts to the bitmap it contains for the purpose of DrawImage. I'll edit my OP for the construction of the bitmap and its graphics. – Jesse Hallam Nov 10 '10 at 19:47
  • Paul, to address your points: As seen in the OP, I use the Graphics provided. I am clipping. I am only invaliding the smallest possible area. GDI objects are static, created at prog startup. The Paint event literally is only one line. Try/Catch blocks are nearly non-existent. – Jesse Hallam Nov 10 '10 at 19:52
  • Understood... i thought that you might be simplifying the function. Have a look at this: (link also included in my answer) http://stackoverflow.com/questions/264720/gdi-graphicsdrawimage-really-slow – Paul Sasik Nov 10 '10 at 19:53
3

Creating your own 'back buffer' instead of using the built-in support for double-buffering is very hard to get performant. What matters a great deal is the pixel format of the buffer. On most any modern machine, any I tried anyway, the 32bppPArgb format is ten times as fast as any other. Favor the built-in double-buffering support for its superior perf.

Another possible loss is your attempt to keep the clipping region as small as possible. That can byte when the region gets complicated. It sounds like you're close to that if you let fast mouse movement generate small rectangular update regions. When the painting falls behind, it almost always will since the mouse gets a higher priority, you could build up a pretty intricate chain of small rectangles. First test this by just invalidating the entire area. Next approach is to expand the area yourself, always keeping it a single rectangle. Reset that when OnPaint runs.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
1

I think you want to create a new class which inherits from Form and then do your drawing in the OnPaint method, rather than listening for the Paint event from the form.

lincolnk
  • 11,218
  • 4
  • 40
  • 61