Solution of WinForm Interface Flicker

Added to the constructor

This.        SetStyle (Controlstyles.doublebuffer | Controlstyles.userpaint |
Controlstyles.allpaintinginwmpaint,
true);

This. UpdateStyles ();

Another attached blog:

Recently, the code has been some optimization, the effect can be after the experiment, but the discovery interface will flicker, specifically the TreeView control will blink, the language is c#,ide as VS2005. After consulting some of the data and using some basic techniques (such as turning on double buffering), it was found to have little effect.

Then use the Profiler tool, find out the bottleneck in each update the interface endupdate operation (use this is to reduce the number of interface updates, but here is not ideal because of the elements in the control), guess about every update. NET bottom is updated to redraw each entity, so the speed is slow, causing flicker. But if so, using double buffering should have a good effect. Looking at the code again, the discovery may be that the update action is too frequent, so reduce the speed, some improvement, but still not.

Continue to look up online, finally find a solution is more appropriate. The original underlying redraw clears the canvas each time and then draws it all again, which is the main reason for the flicker. So overload message Send function operation, prohibit this message. The code is as follows:

protected override void WndProc (ref message M)

{

if (m.msg = = 0x0014)//banned clear background message

Return

Base. WndProc (ref m);

}

Success.

Note: Double buffering is also useful when the update is not very frequent and the control contains elements that are not particularly numerous. Once the element is too much, each update time is relatively long, even if the use of double buffering, still can not solve the flicker problem. Personally think the ultimate ideal method is to ban the removal of background messages.

Attached: Some tried but failed records

1) using SetStyle

On the internet there is said to use the SetStyle function to set the parameters of the control, specifically:

SetStyle (Controlstyles.userpaint | Controlstyles.allpaintinginwmpaint | Controlstyles.optimizeddoublebuffer, True);

These three option parameters the latter is dependent on the former, must coexist, otherwise invalid. And the function itself is protected, so you first need to inherit a control to use it.

This goal is consistent with the previous correct solution and prevents the background from being cleared and dual buffering turned on, but the user drawing options are required, and are all drawn by the user. This requires you to implement the entire control of the drawing, more cumbersome. So this method is not completely unworkable, but requires extra work and is not recommended. I'm not using it either.

2) Use of beginupdate and endupdate

This pair of operations has a good effect on situations where the control needs to be updated in bulk, such as a large number of nodes added in bulk during initialization. The downside is that you can't update it instantly. Therefore, it is not appropriate for frequent updates to the node and want to be reflected immediately to the interface. If you use and do not ban the purge interface message, then the control will appear to flicker continuously, and white base, the content is almost invisible (this depending on the frequency of the degree). Because the interface update is done at the endupdate, too many operations lead to endupdate blocking time is too long, and empty first, updated after, resulting in the interface looks a long time in a blank state.

3) using the Controlstyles.enablenotifymessage option

The role of this option is consistent with the correct solution. The use method is:

SetStyle (Controlstyles.enablenotifymessage, true);

protected override void Onnotifymessage (message m)

{

Write Filter Message code here

}

But the actual experiment shows no effect, do not know what is the reason, did not scrutinize.