Info: Questions about synchronizing animations across multiple elements about velocity HOT 19 CLOSED

Would you consider adding some way to cancel the current animation as well as queued ones?

Yes, I will start considering this as an upcoming feature. No guarantee, of course, but I do think it should be added into Velocity. I will keep you updated.

some elements that are part of the jQuery object do not seem to be animating at all. Am I doing this wrong?

Could you please show me a CodePen/JSFiddle that contains the minimum amount of code necessary to recreate this issue?

Thanks a bunch, @BSSolo :)

from velocity.

...I ended up just pasting the minified code into the codepen.

http://cdpn.io/LIpoF

This should demonstrate the basic problem I'm trying to solve. Elements are updating, and animations are being applied to those elements. On the same selected group of elements, some animations occur immediately, and others do not. It's not clear whether some do not fire at all; perhaps I can refine this further...

Edit: Another question embedded in this is whether or not it's faster to animate multiple elements if you combine them into one jQuery object, and why.

from velocity.

Thank you so much for putting this together. This is a nicely hypnotising demo :)

I will look closely at this and ask you any questions I have. Might take me a bit though.

I see the issue you're mentioning.

The only way to narrow it down to being an issue with Velocity is if you quickly re-implement your demo so that it's built with jQuery's $.animate(). In the process, you'll obviously need to drop color animation (just stick with opacity animation).

from velocity.

The only way to narrow it down to being an issue with Velocity is if you quickly re-implement your demo so that it's built with jQuery's $.animate(). In the process, you'll obviously need to drop color animation (just stick with opacity animation).

I actually haven't used $animate before; I've only used Angular's $animate, which is CSS-based. However, I'll try what you've mentioned. With only opacity animations, there would also only be one animation variant... That will be interesting.

That's the best answer I can give you at the moment because your example is still too complex for me to be able to pinpoint where the issue lies.

Agreed. It's difficult for me to separate the problem from the use case. Thank you for looking into this!

from velocity.

You could also animate something like border width -- some unrelated property just to differentiate A from B from blank.

I really want to help you get to the bottom of this. I am available all day to actually fix an issue if you can prove one exists with a simple use case. Again, I'm very thankful that you're willing to put in the time to get to the bottom of this with me!

Edit: Another question embedded in this is whether or not it's faster to animate multiple elements if you combine them into one jQuery object, and why.

Yes, it is faster when your animation requires unit conversion. Velocity can perform optimizations across elements in a set that share the same parent. Specifically, it can skip recalculating unit conversion ratios, e.g. px --> %.

from velocity.

Yes, it is faster. Why: Velocity can perform optimizations across elements in a set that share the same parent. (Specifically, it can skip recalculating unit conversion ratios, e.g. px --> %.)

What if they don't share the same parent? When force-feeding all starting properties, are there still many more things which you need to check on the DOM?

from velocity.

What if they don't share the same parent?

If elements don't share the same parent, then there is no performance benefit associated with animating an element set.

When force-feeding all starting properties, are there still many more things which you need to check on the DOM?

If you are forcefeeding from px to px, then you're fine. There are no DOM queries that need to be made.

If you are forcefeeding from % to px, then despite the DOM not being queried for the element's starting value, the DOM still needs to be queried regardless to calculate the ratio between 1% and 1px. This is why I recommend that people never change unit types between chained animations (which is very rare anyway) -- Velocity can't work it's "hands off the DOM!" magic.

Good: $elem.velocity({ left: 100 }).velocity({ left: 200 });

Bad: $elem.velocity({ left: 100 }).velocity({ left: "80%" });

However, in terms of noticeable performance: The drawback of querying the DOM is only relevant in high-stress situations. It's not something that you should worry about when, say, sliding in an overlay.

from velocity.

If you are forcefeeding from px to px, then you're fine. There are no optimizations to be made.
Good: $elem.velocity({ left: 100}).velocity({ left: 200 });
Bad: $elem.velocity({ left: 100}).velocity({ left: "80%" });
However, in terms of noticeable performance: The drawback of querying the DOM is only relevant in high-stress situations.

Good stuff. I'll make sure not to switch units, then. My use case is basically a scaled-up version of that example, where many elements on a page are performing simple animations in the background. Since other, more essential tasks will need to be taking place as well, it's extremely important that the overhead from these animations is as low as possible.

from velocity.

Got it, in that case:

• Don't switch unit types.
• Forcefeed.
• Chain animations (don't trigger a new one when the previous one ends... queue them up while the element is still animating).
• Avoid high-overhead CSS properties (box-shadow, border-radius, outline).
• Always use Velocity's built-in features over relying on jQuery. Velocity optimizes everything across its stack; delay, loop, simple property value math, display:none/block, etc., should always be performed with Velocity's native solutions.

Also, you create overhead when dynamically creating a jQuery object, like you do here: $(element).html(' ');. You're also doing it here: $('td').

$(element) forces element to a jQuery object, and that process entails DOM querying.

Try to prevent this from occurring while animations are running. Specifically, cache jQuery objects upfront and reuse them wherever necessary.

from velocity.

Chain animations (don't trigger a new one when the previous one ends... queue them up while the element is still animating).

This one's tough. What if I want to switch the element's animation to something else, before the chained animation completes? (This is what you've mentioned that you are addressing in the 'upcoming feature' above.)

Try to prevent this from occurring while animations are running. Specifically, cache jQuery objects upfront and reuse them wherever necessary.

Right. That was just part of the test case. My actual application uses Angular, and I am working on a directive that animates things with Velocity.

from velocity.

What if I want to switch the element's animation to something else, before the chained animation completes?

That sounds like a parallel animation, which is produced by setting queue: false, but in reality I presume you're asking, "What if I stop the current animation abruptly and start a new one?" Unfortunately, I can't answer that since I haven't implemented abrupt stopping yet :)

from velocity.

That sounds like a parallel animation, which is produced by setting queue: false, but in reality I presume you're asking, "What if I stop the current animation abruptly and start a new one?" I can't answer that since I haven't implemented abrupt stopping yet :)

Right. I cannot run the animations in parallel, for the same reasons that sequences A and B cannot be run in parallel:

1. They can modify the same properties of the element, and I have no idea what would happen.
2. The sequences each consist of two animations which run in series. To my knowledge, it is not possible to run two sequences in parallel which themselves expect component animation to run in series.

But perhaps these reasons are not valid, or there are even more reasons which I'm not aware of yet?

Here's a simplified codepen, still using your library. I've removed the queue and timeout, which should make the timing much easier to monitor.
http://cdpn.io/LjzHv

For the most part, everything animates as it should, as long as the call to .velocity() is made after all animations have finished. For some reason, the attempt to force-feed starting values in the sequence causes the first animation in the sequence to be ignored. Occasionally, cells do seem to flicker instead of animating, but that does not happen very often.

from velocity.

Why are you animating toward 0, then again with another call toward 0?

  $.velocity.animate(element,
    {
      opacity: [0, 1]
    }, {
      duration: duration,
      easing: 'easeInOutSine'
  });
  $.velocity.animate(element,
    {
      opacity: 0
    }, {
      duration: duration,
      easing: 'easeInOutSine'
    });

from velocity.

I thought I was animating from 0 to 1. Looks like I should have read the docs more closely... How embarrassing!

Forcefed start values are passed in as a second or third item in an array that takes the place of a property's value.

from velocity.

;)

from velocity.

:) Updated the codepen. I don't mean to be "that guy" who needs help reading the docs, though, sorry about that.

from velocity.

No problem, man! Don't worry about it. I am glad we had a discussion about performance -- hopefully it was helpful.

So is your demo working as intended now?

from velocity.

Yep, it looks like everything is working as intended. All I'm missing is a way to halt/cancel the current animation, and start the next immediately. Thanks again for all of your help!

from velocity.

It's now on my to-do list to look into. No guarantees it'll be added, but I'm not against its addition. "Watch" this repo to stay on top of which updates take place over the coming days.

from velocity.