Static controls slightly flicker when main window is resized

Question

0.00/5 (No votes)

See more:

INTRODUCTION AND RELEVANT INFORMATION:

I have a complex painting to implement in my main window’s WM_PAINT handler.

I have submitted a picture bellow to illustrate it:

http://pbrd.co/18fNYYp[^]

Main window has static controls, instead of buttons, which have style SS_NOTIFY.

When user clicks on them, certain actions occur in program.

The following picture shows where static controls in the main window are:

http://pbrd.co/18fOkya[^]

Map on the orange panel is an EMF file ,top left and right logos are PNG files, and other pictures are bitmaps.

In order to implement this task, I have decided to draw the entire picture in WM_PAINT, and to put invisible static controls over the images on the picture that correspond them.

Therefore, I only return NULL_BRUSH in WM_CTLCOLORSTATIC handler like this:

C++

case WM_CTLCOLORSTATIC:
    return (LRESULT)( (HBRUSH)GetStockObject(NULL_BRUSH) );

I work on Windows XP, using MS Visual Studio C++ 2008 Express Edition and pure Win32 API.

One note: since Express edition of VS doesn't have resource editor, resource file and resource header were created using ResEdit from here:

http://www.resedit.net/[^]

UPDATE ( UPDATED on December, 5th 2013 ) :

I have added SWP_NOCOPYBITS flag to SetWindowPos call, in my WM_SIZE handler, and performance has greatly improved.

The remaining problems I am facing now are described bellow in the section PROBLEM, subsection UPDATE ( UPDATED on December, 5th 2013 ) :

PROBLEM:

When I resize my window, static controls slightly flicker.

UPDATE ( UPDATED on December, 5th 2013 ) :

Although performance is greatly improved with the changes I have made ( described above ), flickering occurs when I resize window from left to right, and it also happens when I resize it from top to bottom.

If I resize from right to left/ bottom to top the following effects occur, respectively:

right/bottom edge seems to "lag behind" in redrawing, comparing to the other parts of the window.

This effect happens even if I remove static controls.

This is the only thing left for me to solve.

MY EFFORTS TO SOLVE THE PROBLEM:

I have handled WM_ERASEBKGND (returned (LRESULT)1), and I have excluded styles CS_VREDRAW and CS_HREDRAW from my window class-therefore flickering should not be caused because of this.

My window doesn’t have WS_CLIPCHILDREN style, since parts of desktop background are shown where static controls are, after I turn on this style.

I have implemented double buffering for both handlers, in order to avoid flickering.

I have used the tool GDIView, downloaded from here:

http://www.nirsoft.net/utils/gdi_handles.html[^]

to track down GDI leaks.

Each time I resize my window, GDIView shows +4 in column for regions, which means that I leak regions.

I can’t figure out how is this possible, since I do not use API’s that manipulate with regions.

To illustrate exactly what I am facing with, I have made a demo application , with thorough comments:

http://www.filedropper.com/geotermistgrafika[^]

I believe that this is more efficient way, then posting code since it will consume too much space.

QUESTION:

How can I modify code in demo project to get rid of flickering?

Is my approach wrong, and if it is, what is the right one?

Thank you. Regards.

Posted 3-Dec-13 11:36am

AlwaysLearningNewStuff

Updated 5-Dec-13 0:34am

v2

Add a Solution

2 solutions

Solution 1

Flicker can be in part caused by the Windows message WM_ERASEBKGND which you can handle to do nothing, as explained here: http://stackoverflow.com/questions/2473799/gdi-double-buffering-in-c[^] (see answer 3).

A widely used "brute-force" way of removing flicker is the use of optimized double buffering. You accumulate all intermediate changes in buffer and than show all buffer at once. A simple "manual" implementation is shown in answer 2 on the page referenced above.

See also: http://www.robertelder.ca/doublebuffering/[^].

—SA

Posted 3-Dec-13 11:49am

Sergey Alexandrovich Kryukov

Comments

AlwaysLearningNewStuff 4-Dec-13 13:13pm

Thank you Mr.Kryukov, for submitting your solution.
After carefully looking into content of the links you have provided, I must inform you that I have done all of those already at the first place.

Everything you have suggested so far is listed in the section MY EFFORTS TO SOLVE THE PROBLEM

That is why I have submitted a demo application.

I believe that it is the only way for solving this problem, to have someone experienced to look what is done there and try to offer some advice.

I would highly appreciate if you could take a short look, if that is not a problem for you, since I highly respect your professional opinion.

I have tried to document/comment everything, but if there are additional questions, as always, I will promptly answer on any of those.

Best regards.

Sergey Alexandrovich Kryukov 4-Dec-13 13:42pm

Yes, I see, sorry for the redundancy in my answer, probably you are right...
—SA

AlwaysLearningNewStuff 4-Dec-13 13:50pm

No need to apologize, I have assumed that you have given the question a "quick look".

Again, if you could help me with this, I would highly appreciate it, since I am out of ideas at the moment.

I believe that my code is good, but believing and knowing are two different things, that is why I have uploaded demo project and asked for the community to take a look and confirm the validity of my code, or to point out the mistakes.

Also, "flicker-like effect" does not describe my problem in the most accurate way, but seeing the issue "in action" can be more efficient, in my humble opinion.

Thank you again for swift reply.

Regards.

Sergey Alexandrovich Kryukov 4-Dec-13 13:58pm

I cannot promise right now; it would need much more time... I can bookmark it in hope to find some time later.
—SA

AlwaysLearningNewStuff 4-Dec-13 14:03pm

That is exactly what I had in mind.

Holidays are coming, people have responsibilities, and jobs, and I understand it.

I am one of those people too :)

If you could find some time to take a quick look I would be very grateful.

Hopefully we shall "speak" soon :)

Best regards :)

Sergey Alexandrovich Kryukov 5-Dec-13 11:27am

I came to the idea that double buffering is actually not working at all, if you have any considerable flicker. You see, if you have some problems with the rendering, the performance can suffer, but even if you did something poorly but the buffering is actually double, you should not see the flicker. You have to go to the very top of WM_PAINT handler (make sure this message is handled only once) and make sure that 1) nothing is ever written to screen context except some bitmap, and this is done only once per message, 2) nothing is written to screen beyond this message. For example, you can put break points on all GDI operations and figure out in what context any updates happen. The requirement #2 may be violated in certain designs; for example, when you do a free-hand drawing with a mouse, you can draw right on screen and to memory at the same time, but later preserve the this data rendering via WM_PAINT. But for now, make sure it just does not happen (chances are, you will never need it anyway).
—SA

AlwaysLearningNewStuff 5-Dec-13 11:54am

Mr. Kryukov,

Before posting this question, I have tested the demo application, and the original project, with and without static controls.

This is important to know, since after fixing the problem with static controls ( see my answer ), the flickering I get ( once I modify my application according to my answer above ) is the same.

Since this question was about static controls flickering, and was successfully solved, I believe that the smartest choice for me would be to post code/demo app that handles WM_PAINT, hoping that community can help me solve the flickering.

That way, this post would remain short and concise, and most important, on topic.

Thank you again for everything, hopefully we shall "speak" again.

Best regards.

Sergey Alexandrovich Kryukov 5-Dec-13 11:56am

I don't know what do you mean by "static controls".
—SA

AlwaysLearningNewStuff 5-Dec-13 14:13pm

Static control:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb760769%28v=vs.85%29.aspx

I apologize for the confusion my post made to you.

INTRODUCTION AND RELEVANT INFORMATION: section explains everything in great detail.

I strongly advise you to read it carefully and to look at the pictures provided in the links ( it is necessary in order to fully understand the post ).

Hopefully that will clarify everything.

Best regards.

Sergey Alexandrovich Kryukov 5-Dec-13 16:15pm

Oh, gosh, I just forgot the terminology... thanks for clarification.
—SA

AlwaysLearningNewStuff 5-Dec-13 17:00pm

Glad we cleared things out :)

Until next time, best regards.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

AlwaysLearningNewStuff · Accepted Answer · 2013-12-05T04:38:00

The problem was in SetWindowPos API.

I am quoting the developer who helped me to solve this problem:

" When the main window is resized the WM_SIZE handler moves the static child windows.

When a child window is moved, Windows automatically copies the client area of the child control from the old location to the new location.

The main window will then repaint itself in the WM_PAINT handler.

In other words, when the window is resized all the static controls move to their new position and then the rest of the window is repainted. This lack of synchronization appears as flicker.

You can avoid this by passing the SWP_NOCOPYBITS flag to SetWindowPos "

As for the remaining problems about flickering, I think that they deserve a new question, since this one was about static controls flickering.

Thanks everyone who tried to help, and I hereby thank Mr. Kryukov for providing the links that made me realize the problem didn't lie in my implementation of double buffering nor in my handling of WM_ERASEBKGND.