Repainiting Form

  • Thread starter Thread starter J. Edward Rourke
  • Start date Start date
J

J. Edward Rourke

I have a form with about 20 textboxes for data entry. Pop-up forms enable
the user to look up and select data. When the pop-up closes and the main
form is repainted, the drawing of the textboxes is very slow and very
annoying.

Is there a way to repaint the form so that the drawing of the individual
elements is not so noticeable.

Thanks
Ed
 
Hi,

The framework will handle the repaint for you. Your system is
should be fast enough. Min requirements are P3 600.

Ken
 
I put the following code in the form's constructor:

this.SetStyle(ControlStyles.DoubleBuffer |
ControlStyles.UserPaint | ControlStyles.AllPaintingInWmPaint,true);

this.UpdateStyles();

There was no discernable effect.

Does the system automatically perform the double buffering, or must I handle
the painting by overriding OnPaint()?

Or is this machine (P3 , 770 MHz, 640 MB) just too slow for .Net?

Ed
 
Hi,

I appreciate the suggestions, but the problem remains. Even with the "Double
Buffer" code in the form constructor, when the dialog closes the form and
panel backgrounds repaint first while the textboxes, labels and buttons
retain the remnants of the dialog that covered them for a noticeable period
before they too are painted.

I would like to find a method paint all the controls to the buffer and then
push the form's image to the screen all at once.

Thanks
Ed
 
Hi Edward,

In my experience , a form with 20 textboxes only, should not have
repainting performace issue. Could you let me know if there is anything
special with your form and TextBoxes?

To help narrow down this problem, I'd also like to know if the slow
repainting of the mainform only occurres on the pop-up form closing? will
the repainting become slow if you drag the pop-up form over and off the
mainform, instead of closing the pop-up?

If the slow painting is only occurred in closing the popup form, I'd like
to take a look at the code snippet related to the pop-up form handling.

Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.
 
Hi--

I appreciate your interest.

I have put this code in the form's constructor to "Double Buffer" the form.
this.SetStyle(ControlStyles.DoubleBuffer | ControlStyles.UserPaint |
ControlStyles.AllPaintingInWmPaint,true);

this.UpdateStyles();

I expected that this would paint the entire form to an off-screen image and
then push the complete image back to the screen. It had no noticeable
effect.

It appears that the different control types are being painted
sequentially -- first the form background, then the panels, then the
textboxes, labels, buttons, etc. It is this sequential painting that is
ugly-- the panel is repainted leaving the other controls on-screen filled
with the image of the covering form. I would rather live with a delay in
painting the entire image than watching the controls be sequentially
updated.

The answers to the specific questions posed are below along with an
annotated code snipet for the dialog call.

In my experience , a form with 20 textboxes only, should not have
repainting performace issue. Could you let me know if there is anything
special with your form and TextBoxes?

The Form has three main panels --
Left docked with buttons
Top Docked with labels and textboxes bound master table
Bottom panel with data grid bound to child table in same dataset.
To help narrow down this problem, I'd also like to know if the slow
repainting of the mainform only occurres on the pop-up form closing? will
the repainting become slow if you drag the pop-up form over and off the
mainform, instead of closing the pop-up?


If I drag the dialog off the screen, I see the same blink that I see if
Iclose it.

If the slow painting is only occurred in closing the popup form, I'd like
to take a look at the code snippet related to the pop-up form handling.

private void btnOpen_Click(object sender, System.EventArgs e)

{

try

{

// Show dialog to give user a chance to save changes

if (ds.HasChanges())

{

DialogResult rslt = MessageBox.Show("The current data has unsaved
changes.\n" +

"Do you want to continue?", "New Order",

MessageBoxButtons.YesNo,MessageBoxIcon.Question);

if (rslt==DialogResult.No) return; // If No -- dialog clears and repaint is
acceptable.

}

// If Yes -- remnants of the dialog are displayed noticeably in the
textboxes and labels

// that it covers. The dialog is small & only covers 5 controls in its
default location.

// Without the following call to DoEvendt, even this small dialog gives ugly
results.

// The call to DoEvents takes care of it though.

Application.DoEvents();

// The following dialog is preloaded. Class1 holds a static reference

// so it does not have to instantiate each time it is called.

// (The dialog is 738 x 412 pixels in size; the main form is 800 x 600)

DlgSelectPurchaseOrders dlg = Class1.dlgPurchaseOrders;

DialogResult result = dlg.ShowDialog();

// Without the following call to DoEvents the screen appears to freeze

// for a (mental) count of 1-1/2 during which the textboxes & labels,
buttons etc.

// retain the image of the dialog.

// The call to DoEvents reduces the time the image is retained to a short,

// but still noticeable "blink'.

Application.DoEvents();

if(result == DialogResult.OK)

{

OpenOrder(int.Parse(dlg.SelectedPO));

}

}

catch (Exception ex)

{

MessageBox.Show("Failed to open order.\n" +

ex.Message , "Open Order" , MessageBoxButtons.OK, MessageBoxIcon.Error);

}

}

private void btnEditDetail_Click(object sender, System.EventArgs e)

{

try

{

DialogResult result = dlgDetail.ShowDialog();

}

catch(Exception ex)

{

MessageBox.Show("Failed to open detail editor.\n" +

ex.Message , "Edit Detail" , MessageBoxButtons.OK, MessageBoxIcon.Error);

}



}
Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.
 
Hi Edward,

The "Double Buffer" does not help since the redraw code of the TextBox is
not executed in Form.OnPaint method.

This is the way windows repaint the Form, painting the parent control first
then the child controls, however this process should be very fast, It's
still unclear to me why the repaint speed is so slow. Is there any other
codes running background when displaying this form?(e.g. another thread,
timer, and also Sleep method etc) How about the CPU usage?

If you can simplify and seperate this problem from your project , you may
send the small sample project to my mail box to let me have a look at it.

Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.
 
Hi Edward,

I apologize for the late reply,

I had tried your test application on my machine, it's a 1.4G with 512M box,
the Form repainting speed is fine. I also tested this application on a P3
733 with 512M memory box and it worked smoothly too.

Generally, if you enabled the show contents while dragging window. the
underlying window will keep repainting while the above window is moving,
it will cost some CPU time to do repainting, if the CPU doesn't have the
bandwidth to finish the repainting in time, you may see some white block
before seeing the the contents.

So I'd like to know if you will see signaticant repainting delay even if
you dragging the Dialog off the Form slowly?

If the repainting performance is acceptable when moving the dialog window
slowly, IMO this is a correct behavior, maybe you need turn off the "Show
Window Contents while dragging" on the client machine for better
performance, ( this option is under "Display
Properties"->"Appearance"->"Effects".)

If the repainting delay is still significant, probably this issue is not
caused by the CPU performance only. In my experience some apps which use
global message hook might cause the repainting delay. You may check if this
delay could be reproduced on a clean machine. If the OS is Windows XP, you
may also try turning off all the visual effects in "My
Computer"->"Properties"->"Advanced"->"Settings" page.

If you have anything need help, please feel free to post your update to
this thread.
Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.
 
Hi,

I appreciate your efforts on my question. I have learned a lot since this
started--but not enough to resolve my problem.

I probably oversimplified the sample code I sent. It is faster than the
actual form. On a fast enough machine, the effect is not detectable.
However, on my P3 700 Mhz machine, I distinctly see the sequence of the
repaint-- first the background then the form /panel background then the
controls ( labels & textboxes). On the sample form, it is just an annoying
flicker.

The production form is slower. When the dialog is dismissed, the visual
elements of the dialog that covered labels and textboxes remain visible for
a significant period--a count of between 1 and 2 under the heaviest
application load.

I believe that the effect is the consequence of two factors. One, as you
pointed out and I have seen for myself, repainting is performed in
steps--form background, then panels, then labels and textboxes. Two, it
appears to be sensitive the application load (updating a Dataset and
executing the binding code that passes the new Dataset values to the
controls, for instance) at the time of the repaint. It appears to me that
since each control is responsible for painting itself, the repaint process
probably shares CPU cycles with whatever else is going on in the application
at the time. This probably maximizes overall efficiency at the expense of
the screen paint which then becomes apparent on slower machines.

In my research, I could find no practical way to manage the repaint process
or to create a visual effect that would hide the process from the user. I
have therefore redesigned the UI to eliminate the use of the dialogs on this
project.

Ed
 
Back
Top