Forum

This thread is related to the jittery behavior of docking windows while hidden/shown. I mentioned this a few times before when I compared that behavior with the one found in Visual Studio.

Looking in ExtControllerTabbedFeatures.cpp, there a couple of places where the duration of an eventual ’sleep’ is calculated:


                clock_t nNewAnimTime = clock();
                clock_t nDuration =
                    nLastAnimTime - nNewAnimTime;
                if( nDuration < CExtControlBar::g_nAutoHideAnimationStepTime )
                    ::Sleep( CExtControlBar::g_nAutoHideAnimationStepTime - nDuration );
                nLastAnimTime = clock();

Shouldn’t the duration be calculated instead as:

                clock_t nDuration =
                    nNewAnimTime - nLastAnimTime; ?

nDuration in the official source code is always negative, which makes nDuration smaller than the animation step time and therefore, a Sleep is always triggered since CExtControlBar::g_nAutoHideAnimationStepTime - nDuration is always positive. In fact, the slower the machine, the longer Sleep() time because nDuration is probably proportional with time taken to redraw...

I changed the nDuration using the second formula and the jitter is far less noticeable (comparable now with Visual Studio). Can you please confirm and if necessary fix that code in the next release.

Thank you,

Bogdan

Thank you for reporting this issue. Two integer values returned by two invocations of clock() API can be less than each other because clocks can overflow the integer limit after long time. So, a valid solution is to check whether the difference is positive or negative in any case:

                clock_t nDuration = nLastAnimTime - nNewAnimTime;
                if( nDuration < 0 )
                    nDuration = -nDuration;

There are two places of nDuration computation in the .../Prof-UIS/Src/ExtControllerTabbedFeatures.cpp file.

While theoretically it is possible to have an overflow on a long integer, what it’s eventually being calculated there is the difference between two moments in time.

According to MSDN, the clock() routine calculates how much time the calling process has used since the start (in milliseconds). Let’s assume nLastAnimTime is a very large integer, while for nNewAnimTime clock() has rolled over and is a very small integer: even in that case nNewAnimTime-nLastAnimTime is a positive difference. The difference should also be positive if both values are negative. The only case where the difference is negative is when between nLastAnimTime and nNewAnimTime there are more than 2ˆ31 milliseconds (i.e., hundreds of hours). Given the fact we are talking about two subsequent redrawings of a sliding docking window, there are probably other things you should worry about and not the overflow.

Calculating the duration as nNewAnimTime-nLastAnimTime is less obscure and doesn’t need the post check if (nDuration<0).

Thank you,
Bogdan