WinForms painting – SuspendLayout, dblBuffer etc

Play with these settings on your various controls and see how that works.

The application form has a wizard-like container control that can host multiple pages.  Each page is a rich UserControl with complex and nested child controls.

The wizard-container is showing the first page (visible, dock-fill), and the second-page is hidden (visible=false, enabled=false, and/or not even in the controls list).

 

=> How would you transition from page1 to page2 to acheive slick rendering.  In particular, the nicest result is probably a short pause (no visual change to page1) while work is done, then ‘pop’ the new screen is fully rendered.

=> I find this scenario very hard to get right in general and every application that does this sort of thing has to be custom-fiddled to get a nice result.  I often test variations of orderings of Update/Refresh/BringToFront/Hide/Show and the results are often very suprising (eg change one minor ordering and the visual outcome is drastically different).  Sometimes I try manual rendering of the entire control (including all child controls) to back-buffer, but I haven’t had any success with that so far.

How do other people with this scenario?

Any suggestions appreciated.

I don’t know what you’ve done and haven’t tried anything like this myself, but here’s a guess.

When a control isn’t visible (e.g. when it’s hidden behind another) then the standard OnPaint doesn’t work, because the associated Graphics region (which paints to the screen) is clipped.

What you might be wanting to try, therefore, is draw to a non-screen Graphics object, which you can then blit to the screen.

The example shown in the help for the BufferedGraphics class might help you do that.

I don’t know how to use BufferedGraphics to buffer output from standard controls (I can see how to do it from custom controls). Maybe it means implementing a MyRender method in your form, which constructs a PaintEventArgs using a Graphics instance obtained from a  BufferedGraphics instance, and which invokes the OnPaint method of the various controls in the form (passing your own PaintEventArgs instance to the controls’ OnPaint methods).

FWIW, printing too entails drawing to a non-screen buffer; I’ve never implemented printing so I don’t know whether that works with standard controls (e.g. whether printing persuades them to render to a non-screen Graphics object).

The above is something along the lines of what you’ve been trying, but beware that I’m not confident that this is the best or standard way to do it.

Also I don’t know about “BackgroundWorkers”: does that slow down rendering? A tiny bit of flicker or shimmer is normal (and so, expected and barely noticeable) at the best of times when a screen is refreshed (e.g when you scroll a multi-line edit box); but not a lot of flicker.

1. Place the ‘real’ controls (one at a time) in the normal tab order as the user tranverses the image, redrawing that control to show any changes, or put the ‘real’ control where the user clicked if not folloing the tab order.

2. In the situation where only one record would be live, pop-up a dialgo witht ht real controls and redrraw the image when the dialgo was dismissed, showing the changed data.

public void BeginUpdate()

{

  SendMessage( this.Handle, WM_SETREDRAW, 0, 0);

}

public void EndUpdate()

{

  SendMessage( this.Handle, WM_SETREDRAW, 1, 0);

  Parent.Invalidate(true);

}

http://www.syncfusion.com/FAQ/WinForms/

Fixing this doesn’t solve all the redraw issues, but it can definitely speed things up.

after each constructor and then in the load event I say

this.Visible = true;

this.Update();

Doesn’t really solve it entirely but relieves the pain. On second opening its relatively ok – not so much visible drawing.  The first call is what takes time and from what I gather you can only work around this perhaps by ngening.

Also check performace on a release build.  Things might look a little better also if infragistics controls are running out of GAC it might slow you down a touch.

These 3rd party custom controls carry a penalty one way  or another. I swapped out a combobox I was too lazy to owner draw and the performance change was remarkable.

All the best