Panel Animation Speed

[MarcT]

How can I make a ContentPanel expand and collapse faster?

[PhiLho]

I haven't time right now to test it, but from a quick look at the sources, slideIn() exists with two parameters, the second being a Fx object.
You can build such object with a duration parameter.
I would try to change this parameter.
In short:

cp.getElement().<FxElement>cast().slideOut(Direction.UP, new Fx(100)); // Default at 250

Again, untested...

[MarcT]

Thanks, PhiLho, that pointed me in the right direction. And it would cause some animation to happen. Unfortunately, it misses all the other side-effects that happen in the ContentPanel.onCollapse() function (hiding the collapse button during the anim, calling Pre- and Post-Animation handlers, etc). Right there in onCollapse(), the CP is creating its own Fx object with a hard-coded 500ms speed.

So at the moment, the only way to change the speed and still have all the surround stuff happen appears to be to sub-class ContentPanel and override onCollapse/onExpand, copying all the code and changing the speed. Which feels really hacky to me. Any option I'm missing?

Sencha, a feature request: Add an int param to collapse()/onCollapse() (and expand()/onExpand()) that allows us to specify the speed of the animation. It would also probably be useful to allow us to specify the Fx object itself (unless those are single use or there are other downsides I'm missing).

Thanks!

[Colin Alworth]

After some quick discussion with a resident animation expert, and a look at the general Fx api (and where we may be taking it in the future), there are a surprisingly large number of things to consider. Here is the short version:

• Adding a parameterized overload for expand/collapse would just push the problem to consumers of the ContentPanel, such as border layout or accordion, so those would likewise need overloads - this makes the issue mostly one of configuration
• Fx instances can be reused. However, the same instance cannot be used for more than one concurrent animation, as it tracks the current state of the animation (and the events Fx exposes would be nonsense if running more than one at once)
• CSS animations. The general outlook seems to be that these will be preferred in a lot of situations, where you can do the same work as a programmatic animation, but they are managed totally differently. It won't make much sense to expose them as an animation property of the ContentPanel itself, but either as implementation details of the ContentPanel, or as part of the appearance itself.

My proposed fix, based on this, would be to only expose the animation time as a setter on ContentPanel, so it can be used in any newly created Fx instance, or any future animation source. The question I would then pose for you, consumers of the API, is does it make sense to only have one setter, or would it be better to have one for expand, and one for collapse. My initial thinking says just one, as the animations should be symmetrical.

Other thoughts, or pieces I am missing?

[MarcT]

Seems like it's always more complicated...

I'd be fine with a single setAnimSpeed() than handles both expand and collapse. Thanks for the quick reply!

[Colin Alworth]

If it was easy, we'd have already done it, or someone else would have done it so we didn't have to!

I think we've settles on just a single getter/setter for these animations, but I'll make sure that when we make a decision, it is posted here.

[Colin Alworth]

I've just checked in a change for this into SVN, and it will be available in the next release. ContentPanel has a setAnimationDuration(int) and a getAnimationDuration() method that should allow reading and writing this property.

In reading the thread from the top, another idea struck - remember that you can always just disable the animation of the content panel, with ContentPanel.setAnimCollapse(false).