Request: option to disable hidden pane animatino

[Scott Bilas]

I'd like to request an option to disable the animated panes. For example, if the Project pane is hidden, and I hit my hotkey to show it, it animates to a visible state. This is normally fine but if my machine is bogged down running a build in the background then it can take 10-20 seconds for the pane to fully render.

Actually, how about two things:

  1. Add an option to globally disable animations for HE.

  2. Update animation code to be sensitive to time. Rather than expanding x pixels every update, update x pixels per time interval. That way, if the machine is running slow the pane still opens as fast as it should, it just skips frames that it's dropping.

Thanks!

[alex]

Hi Scott,

I have understood the problem, but from my point of view it is a low priority.
1) this situation is not very often happens
2) you can use another way to hide panels (expand function for document window - double click on tab or icon near tab scroll buttons)

There are not too much other animations in HE (generally could not remember others). What is already done is disabling of smooth scrolling and layered windows when running on terminal server.

I would say option 2 suggested by you looks more preferable and probably I would change logic as you have proposed, but do not know when. If somebody else would also complain about this, probably I would think about xml flag to disable panel animation.

Best regards,
Alex.

[Scott Bilas]

Yes I think option #2 is probably the better solution to do first. I hope you have time to do this because I run into this problem a lot. My machine is busy very often and I often have to wait a long time to just open another file in my solution due to the animation.

I assume you're using a WM_TIMER or something to get the callback for animation, and in there doing 'width += some constant'. If you instead make that constant dependent on the delta time between the current update and the last time, it would be a time-independent animation and look the same on all machines regardless of system load. So something like: width += max(1, min(target width - current width, (now - last time) * pixels per sec)).

I know you're very busy though, and not many people will probably run into this. So I understand that this is very low priority for you. No worries.

[alex]

Ok.

Implemented with 14.43.660 - try it.

Best regards,
Alex.

[Scott Bilas]

Yes, this fixes it in 660! Thank you, I wasn't expecting a fix so soon.

One minor thing I noticed: when my machine is slow and the pane is animating, it's erasing the background with black but it would look better if it used the panel's gray background for the erase brush color instead. (It's hard to see unless the machine is bogged down.)

This doesn't bother me at all but I figured I'd mention it in case you were interested. Sometimes the main window also erases the background as black when things are very slow so it may be a general window class thing or something.

Anyway, I'm very happy that the pane now animates open the same speed regardless of system load. Thanks!

[alex]

Hi Scott,

I do nothing on erase background to reduce flickering (this is standard practice).

Code: [Select]

BOOL CGuiControlBarBase::OnEraseBkgnd(CDC* /*pDC*/)
{
return TRUE;
}at least I try to do this everywhere.
I do not know how this looks on slow machine, but probably like black boxes...

Best regards,
Alex.

[Scott Bilas]

Are you setting a background brush for the window or its class? If you don't erase the background then it falls back to Windows doing the erase itself...I think.

The black color is pretty weird because I've never seen Windows use that anywhere else for a default background color. Typically it gets the system window background color to use instead.

[alex]

No, I am not replacing the brush for window. And from my experience black color comes form NULL (invalid brush). But...
default erase background should not be processed, because of the return TRUE;
For example here it is explained: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/3cf0155f-af7b-4c94-b21f-7dbd8c7e41e5
And here is docu for OnEraseBackground: http://msdn.microsoft.com/en-us/library/a0a52fkz(VS.80).aspx?ppud=4
If you would do filling of the background of the window with default color, you would get problem with your child controls also, because I think their regions would not be clipped.

Normally OnEraseBackground should be called for dialogs, where your have statics that draw directly on main window.

I would keep in mind this black updates (I have solve something like this for tooltip, but there it was WM_PRINTCLIENT) but do not know when.