Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
Dum

New Velocity.js Animation Library features GSAP

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Have you guys checked this out?

 

http://julian.com/research/velocity/

 

What do you think of the comparison test? I noticed that he was doing some stupid things like queueing up all the animations again for each count, and also claiming that GSAP doesn't 'play well with other libraries' (because he's using the jquery plugin instead of plain gsap). Surely, gsap would perform better if he was using Timelines, no?

 

 

Link to comment
Share on other sites

Great question. I have a lot to say...

 

First of all, Julian (VelocityJS's author) seems to be a super nice guy and we have already been in contact about the article and engine. Apparently he's a big fan of GSAP and it inspired his work which is cool. He's in the process of changing some inaccuracies in the article regarding GSAP (some of which were totally my fault...more on that later...) 

 

He did a very nice job of speeding up jQuery's animation performance. Kudos to him. He clearly put a lot of thought and effort into VelocityJS. We're kindred spirits in terms of being performance geeks :)

 

His performance comparison originally used a version of the jquery.gsap.js plugin that contained a bug that caused it not to perform well in that particular scenario and in fact it interfered with other animations afterward. That was completely my fault - I misunderstood something about the way jQuery queues and dequeues things. The problem had nothing to do with GSAP - it was the jQuery plugin that was basically the glue between jQuery and GSAP, funneling all jQuery.animate() calls to GSAP for speed boosts. 

 

That bug has been fixed and is online now. Julian updated his files promptly and is in the process of changing the verbiage in his article. I created a codepen of his test with my updated files here: http://codepen.io/GreenSock/pen/pmknI/

 

As you can see, GSAP performs much better now, even though it's still going through a jQuery plugin (it'd be faster to use GSAP's API directly). 

 

There are some key differences to keep in mind when evaluating GSAP and VelocityJS:

 

Project goals

VelocityJS is a jQuery plugin, not a full-featured animation platform like GSAP. Therefore, VelocityJS has many of the same limitations as jQuery's API. 

 

Features

VelocityJS is not built for complex sequencing, super flexible timing and overlapping of tweens, runtime controls like seek() or timeScale(), bezier tweening, momentum-based movement like Draggable/ThrowPropsPlugin, animation of non-DOM objects, etc. GSAP can be used with canvas libraries, WebGL, generic JS objects - whatever you want. As Julian says, it's the Swiss-Army knife of animation. It can do almost anything you want. The up side for VelocityJS is that it has a smaller file size footprint because it doesn't have to accommodate so much flexibility and features. And the API is narrower, so it's probably easier for folks to get up-and-running with. But GSAP can do a LOT more - you probably won't find yourself hitting a wall no matter how ambitious you get, and you can use the same engine across all your projects (non-DOM too). 

 

Timing

GSAP prioritizes timing accuracy whereas it appears as though VelocityJS (and I think jQuery in general) front-loads the initialization code (parsing/recording starting values), thus you’ll notice that under pressure VelocityJS has long pauses between the loops in the test above whereas GSAP doesn’t.

 

Every animation in GSAP remains perfectly synchronized whereas Velocity (like almost all other engines) experiences some time drifts that can cause clumping and timing irregularities as seen here: http://codepen.io/GreenSock/full/e3ac33404937de0eb77c789323367da8/. GSAP also has an exclusive lagSmoothing() feature which is described here: http://greensock.com/gsap-1-12-0. None of these make Velocity "bad", of course - I'm just trying to describe some fundamental differences in how the two engines handling timing. You decide if these matter to you.

 

Consistent transforms (x/y/scale/rotation)

This is a BIG deal in my opinion – VelocityJS doesn’t implement transform components in a consistent way. GSAP does. For example, if you use VelocityJS to animate translateX, then rotate, then scale, then translateY, you’ll get a completely different result than if you do those very same animations in a different order. As an animator, you don’t always know which transforms happened previously (or in which order) – you just want the scaleX to be 2 or the y position to be 300. If I animate y to 300 but it was rotated 90 degrees earlier, the element might start moving along the x-axis instead! 

 

Oh, and transforms don't work with VelocityJS in IE8 or earlier. GSAP makes transforms work all the way back to IE6 last time I checked. 

 

Conflict management (overwriting)

As far as I can tell, VelocityJS doesn't have any conflict management. Most animation engines don't actually so this isn't unusual at all. But without conflict management, animations can fight with each other. Plus VelocityJS seems to implement some caching of property values that can be problematic in certain situations. Here's a codepen that illustrates the difference:

http://codepen.io/GreenSock/pen/0f53117c64a730c92b68905772d07dd1

 

You'll notice that the VelocityJS animation jumps around in a way that some would consider surprising, although I can't really fault VelocityJS because it's very rare to find an engine that handles this kind of stuff for you. It's one of those details that's really useful in a full-featured animation platform like GSAP, but isn't as crucial when you're just doing one-off tweens that have little risk of overlapping. 

 

Open source

VelocityJS is MIT-licensed open source which many people LOVE. The down side is that the majority of MIT-licensed projects that I've seen stagnate and die and/or don't offer solid support because there's no funding mechanism in place to sustain it. But hey, it's free. GSAP, on the other hand, is also free for the vast majority of use cases (including most commercial ones) but there is a funding mechanism in place (Club GreenSock) which has allowed us to build and maintain these forums, innovate the product itself, crank out videos and detailed docs, etc. Some of the biggest businesses on the planet rely on GSAP in their sites/apps/games, and they feel more comfortable using a product that has a long track record of support, prompt bug fixes, and continued enhancement. We have heard from several companies who refuse to use most open source stuff because they think it's just too risky. Again, this isn't a "right" or "wrong" issue at all. The projects have different goals and it seems to me like an MIT license for VelocityJS is a great choice. 

 

In terms of performance, now that the jquery.gsap.js bug is fixed and we made some performance improvements in the latest GSAP update, I have yet to see a case where VelocityJS is faster. In both of the speed tests I've tried, GSAP was the better performer. However, Julian has done an excellent job of building a very fast jQuery plugin, so my hat's off to him. Plus he seems like a very cool guy. 

 

I'd be curious to hear what others say after trying VelocityJS and comparing it to their experience with GSAP. 

  • Like 6
Link to comment
Share on other sites

Really awesome, Jack. 

 

Your codepen demo does indeed appear to be the same demo code as Julian's, yet GSAP performs closer to my expectations of it then what I was seeing on Julian's site (I knew something had to be off).

 

Now that you mention it, I never really realized how nice all the matrix transformations you do in gsap are. You're right that those are pretty huge if you ever get weird results animating those in a different library.

 

Sadly, though, I can't offer my experience working with velocity in a production environment since jQuery is a forbidden taboo on my team. :)

  • Like 1
Link to comment
Share on other sites

Great clarification and explanation of the differences Jack!

Link to comment
Share on other sites

  • 3 months later...

can someone port this demo over to GSAP.  I'd love to see the differences in the code as well as the speed / performance, etc.

 

http://julian.com/research/velocity/demo.html

 

and by port, i mean you can improve it.  if timelineMax will make it better, for example.

Link to comment
Share on other sites

Sure, I've put it on Codepen here

See the Pen soLrF by jamiejefferson (@jamiejefferson) on CodePen

 

The velocity demo uses transforms only, which means it has to calculate the screen width to determine x/y positioning. I swapped that to use left/top which looks mostly the same (only a bit of jerkiness on the zoomed in circles due to non-subpixel positioning). With left/top the whole animation is responsive to window size changes though.

  • Like 4
Link to comment
Share on other sites

Jamie's example is excellent. The up side to using top/left is that it can be "responsive". The down side (as he indicated) is that in some cases it can perform worse due to the browser having to do layout calculations, and top/left cannot do sub-pixel rendering. Here's a slightly tweaked version of Jamie's codepen that uses transforms and is more equally matched with what Julian's demo does:

http://codepen.io/GreenSock/full/854b033c93a77aec48630498a99412be/

 

As you can see GSAP is just as fast or faster. But again, Julian did a nice job optimizing Velocity, so it certainly isn't as if it's "slow". 

Link to comment
Share on other sites

Jack - you've swapped the from and to values for x/z/y in the dot tweens in that example, and the .to(container... isn't updated with $  :)

Also I noticed that there is no more comparison to GSAP on the Velocity website  :(

Link to comment
Share on other sites

Hm, I thought I followed Julian's code in terms of the to/from x/y/z values but I could be wrong. Either way, I'm not sure it really matters. :)

 

And yes, Julian removed all comparisons to GSAP from the Velocity site and his articles. I don't think he's looking to compete with GSAP on performance; in fact, he wrote an article that will be published soon in a rather popular publication, and his article features both GSAP and Velocity (not comparing/competing, but rather describing them both as very performant options that are better than CSS animations and other libraries). I really can't blame him for initially comparing it to GSAP on his site because there was a bug in the jquery.gsap.js plugin that made it not perform nearly as well as it should, so it made Velocity look better in that very specific scenario. I fixed that bug promptly, so there's no point in having GSAP in his comparisons since it doesn't make Velocity look better (GSAP is just as fast or faster). Again, that's totally understandable. If anyone is wondering about performance, I'd encourage them to do their own tests. 

 

Thanks again, Jamie, for putting together that demo using GSAP. Very cool of you. 

  • Like 2
Link to comment
Share on other sites

No worries Jack; the performance would be the same regardless.

 

The values being reversed causes all the dots to spawn in the top left quadrant instead of centering the 'star' field. It's something that confused me too, but it's part of the Velocity syntax to have the start values as the last array value.

 

For comparison:

See the Pen 854b033c93a77aec48630498a99412be by GreenSock (@GreenSock) on CodePen

See the Pen ImxDk by jamiejefferson (@jamiejefferson) on CodePen

  • Like 1
Link to comment
Share on other sites

By the way, Jamie, you should set pointer-events:none on everything and overflow:hidden on the body in your codepen to improve performance (that's what Julian's example does). Otherwise, the browser has to keep updating the scrollbars on every render and watch for mouse interaction which eats up resources. 

  • Like 1
Link to comment
Share on other sites

Thank you Jamie for the awesome demo and thank you Jack for adding your masters touch.  I know that greensock performs great and I know that velocity performs great as well.  I was really impressed with Julians video cast where he showed off velocity as well as all the code behind it and why he did what he did.  I loved his demo.  When I saw it I thought about tweenmax and using timeline max and what it would look like and you both hit that on the dot.  with the 2 timeline calls you can really isolate each individual section and give artistic impression and change things up quickly to experiment.  thanks for your great work guys! 

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×