Jump to content
Search Community

WAAPI-Powered GSAP? Unlikely

GreenSock test
Moderator Tag

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

Well written and great info Jack. :)

 

I’m glad to hear that you’re not trying to force GSAP onto WAAPI. It would be cool to access additional threads, but everything that we would lose in the process would make that a bad trade. Sacrificing custom easing would be terrible. :( Easing is the foundation of great animations.  B)

 

As much as I enjoy writing code and learning more and more about JavaScript by hanging out here, at the end of the day I’m an animator first and a coder second. Whether it’s GSAP, After Effects or C4D, I just like putting those pixels into motion. GSAP allows me to do that with confidence.

 

I have a feeling as people try to push WAAPI, they’ll be somewhat frustrated with the limits and browser inconsistencies. That’s one of the most beneficial features of GSAP – it just works. I can animate first and not have to worry if it’s going to work in the various browsers. If a bug is encountered in some new browser version, you usually have it fixed quickly. Plus there's a plugin for every occasion. 

 

I’ll certainly mess around with WAAPI, but I can’t see myself using it for much of anything important when I have access to GSAP. As it matures, who knows? We’ll see where it goes from here.

 

GSAP is already the leader and I’m sure when 2.0 happens, the well-deserved reputation for quality and performance will only grow.

 

There’s my two cents worth.

:)

 

  • Like 4
Link to comment
Share on other sites

  • 1 month later...
On 10/26/2017 at 1:16 PM, GreenSock said:

I've been asked several times about the likelihood of GSAP being built on top of WAAPI someday. I figured it'd be best to just publish a blog post about it. Here ya go: 

 

https://greensock.com/waapi

 

 

So what is the edit at the bottom about? What kind of solutions are they looking at, or possibly thinking about?

 

Right now I'm just not seeing a lot of value in WAAPI from an animator's perspective. The performance is nice, but it's not a game changer. And there will be other ways to improve GSAP performance in the future. Have you looked at Houdini

 

The cornerstone of Houdini is the CSS Typed Object Model. It's CSS with types e.g. number, length, matrix, keyword, color. The current CSS object model is string-based. To animate the DOM, the browser and GSAP have to spend a lot of time parsing, converting, and building string values, which is dumb. A matrix should not be a string. 

 

With Typed OM, that process will be mostly eliminated. 

.box {
  height: 30%;
}

 

// What's the height?

console.log(getComputedStyle(box).getPropertyValue("height"));
// "259.5px"

console.log(getComputedStyleMap(box).get("height"));
// CSSUnitValue {value: 30, unit: "percent", type: "percent"}

 

That can provide a HUGE performance boost. I don't remember what talk I heard this from, but somebody benchmarked animating transforms on 1000 elements using rAF. They found that the browser was spending about two-thirds of the frame budget just parsing the transform strings. When benchmarked using Typed OM, the parsing time was virtually eliminated. 

 

The goal of Houdini is to make looking at caniuse.com a thing of the past. You will no longer need to wait around for a browser to implement a feature. Just copy and paste the raw code that makes it tick! One part of that raw code might be paint worklets using the Custom CSS Painting API. It allows you to draw stuff directly to an element's background, border, content, mask, etc.

 

eJvcLls.gif

 

 

Paint worklets run in a separate thread, so it could be used to improve performance. I was looking at how GSAP could be leveraged inside a separate thread, but some changes would need to be made to the library. A worklet has no access to the window or document, and there are no timing mechanisms like requestAnimationFrame or setTimeout. An animation would have to be manually stepped setting something like a time or progress value.

 

And a paint worklet is stateless, so you can't save/store values. You can create instances of stuff, but the painting has to behave almost like a pure function. One reason for that is because the browser can create the same worklet multiple times, and will kill them as it sees fit. Another reason is the same paint worklet can be called multiple times for different properties or different elements.

 

I know that sounds like using GSAP would be pointless, but it could still be leveraged. On the DOM side, GSAP can tween something like a progress or time value, and in the worklet we can take that value, and plug it into a tween or timeline to interpolate values on some objects. We can then use those values to paint stuff on the element. It's works just like a canvas animation.

 

Here's a demo that animates Google's logo. Yeah, I copied most of it, but look at the paint code. It's calling an interpolate function everywhere. That could obviously be replaced with a tween or timeline. Even better, using the MorphSVG plugin with canvas Path2D objects which can draw SVG paths. On the DOM side, I'm using GSAP to tween a simple --scale property, which is what drives the morphing animation. Well, there's also a --total-time property, but that is being updated by a rAF call. It's used to animate the balls up and down when the --scale is at 0.

 

Note that in order to view this demo, you must use Chrome or Opera, and enable the Experimental Web Platform feature. You can always disable it afterwards if having it enabled scares you. You can copy and paste this into your address/search bar to jump directly to the flag.

about://flags/#enable-experimental-web-platform-features

 

See the Pen ?editors=1010 by osublake (@osublake) on CodePen

 

And once you have that flag set, be sure to check out some of the Houdini demos here.

https://lab.iamvdo.me/houdini/ripple

 

Houdini is still evolving, so there's lots of room to make suggestions and get something incorporated into the spec. Getting the WAAPI spec to change will much harder as that's more mature. Houdini does have a draft for an animation worklet, but right now it seems to be geared towards doing scrolling animations with WAAPI. :rolleyes: I would much rather have a general purpose JavaScript animation worklet that doesn't depend on WAAPI or DOM elements.

 

  • Like 7
Link to comment
Share on other sites

13 hours ago, OSUblake said:

So what is the edit at the bottom about? What kind of solutions are they looking at, or possibly thinking about?

 

Well, Brian seemed eager to find solutions and he mentioned a few that might address some of the points in the future (like a spec for custom easing...but that's probably way far in the future...if ever). He also said he thinks that additive transforms could be leveraged to solve the whole "independent transforms" thing as long as GSAP can do all the tracking/recording under the hood. I like Brian - he's always been very kind and professional. 

 

I think it's really cool that spec authors like him express a willingness to make changes to solve these issues, but I'm not sure much will come of it (at least in the next couple of years). Not because of Brian, of course - it's just that there are a lot of things that are outside of his control (stakeholders, committees, browsers, politics, trends, etc.).  These specs seem to move at a snail's pace. Well, the specs and then the browser implementations. 

 

13 hours ago, OSUblake said:

They found that the browser was spending about two-thirds of the frame budget just parsing the transform strings.

 

Oh, don't even get me started on that! Makes me angry, quite frankly. I think it's ridiculous that we're forced to take numbers, convert them to a concatenated string with a bunch of extra stuff (most of the matrix values may not have changed at all), and shove them at the browser which then must decompose the whole thing back into numbers. Why...WHY don't they just let us set numeric values directly, like element.transform.matrix[0] = 1.2? I wouldn't be surprised if doing that would completely wipe out the advantage CSS has with transform animations on a different thread. 

 

Houdini looks really cool, Blake. Can't wait until that stuff is actually usable widely. I always get sad, though, when it dawns on me that it'll probably be years and years. When it becomes more realistic, I'd love to kick ideas around with you regarding Houdini in GSAP. [Setting a reminder for mid-2019 ;-)]

 

I share your sentiment about WAAPI not seeming very exciting at this point. GSAP has been able to do everything WAAPI promises plus a lot more...for years. The main exception, of course, is the separate thread transforms/opacity which would be cool but I doubt the performance difference would even be noticeable in most projects. There are soooo many down sides to using WAAPI (compatibility, lack of features, etc.) that it doesn't seem appealing. But I guess for simpler projects that have very strict file size requirements and only need to run in the most modern browsers, it could be a nice fit.  

 

Thanks for sharing the info about Houdini and your take on WAAPI, Blake. It's always stimulating to chat about this stuff with you, @PointC, @Dipscom, etc. 

  • Like 2
Link to comment
Share on other sites

Quote

The goal of Houdini is to make looking at caniuse.com a thing of the past. You will no longer need to wait around for a browser to implement a feature.

 

@OSUblake You mean in future of future :D right? I mean when all browsers start supporting CSS Typed OM and then in future some new feature comes, that can be supported by raw code, right?

 

Last night I read your post it felt like it will be challenging to work with everything Houdini offers but after going through the code it looks pretty straight forward.

 

EDIT: Probably missed my question?

Link to comment
Share on other sites

9 hours ago, Dipscom said:

I also wondered if they'd be 'inspired' by GSAP on how it structures the sequential lines of code for timelines.

 

I don't think so. About the only thing a WAAPI timeline has in common with a GSAP timeline is the name. All I can say is that you should give it a test drive. If you like creating CSS animations keyframes, and are familiar with CSS animation terminology and properties, you'll like WAAPI. 

 

Now don't get me wrong, I would actually like to see @GreenSock add something like keyframes to GSAP, I've just never asked for it. It would be really helpful for situations that otherwise might require you tween the progress of a timeline with another animation, but I certainly wouldn't want to use keyframes as the basis for all my animations. 

 

9 hours ago, Dipscom said:

I've wondered in the past what is going to happen when the WAAPI become more widespread. 

 

Weren't you the one that brought up cargo cult programming?

 

As WAAPI becomes more widespread, it's going to be like 2013 all over again. But instead of people saying that CSS animations are better than JS animations, the mantra will be that CSS and WAAPI animations are better than JS animations.

 

Why? Because that's what some performance gurus over at Google said, and they know what they're talking about. And some of the stuff I've read on Twitter and Medium is also pretty convincing. I mean, just look at this comparison. This is what happens when the browser is busy, which apparently happens all the time. 

 

The JS animation on the left is all jank, while the WAAPI animation on the right doesn't skip a beat. Amazing!

 

fX7ZEHl.jpg

 

 

Don't believe me? See for yourself. I spent a lot of time coming up with an algorithm that accurately simulates how a normal site behaves.

 

See the Pen zpxXKX?editors=0010 by osublake (@osublake) on CodePen

 

 

That demo says all that needs to said. WAAPI is clearly better. No further testing is required. 

 

PglkHq2.jpg

 

 

Oh wait... a challenger appears. It's called "Something other than transforms or alpha".

 

See the Pen qpEGar?editors=0010 by osublake (@osublake) on CodePen

 

Oh how the tables have turned! Turns out that WAAPI is indeed susceptible to jank. Not only that, but the jank can be magnified if the animation gets out of sync, looking like a video game with really bad collision detection, glitching through walls and stuff.

 

So locking the browser up to show how jank affects JavaScript animations is just stupid, and can actually disprove what you're were trying to prove. Besides, if your site really has that much jank, then one or more of the following must be true.

  • You're not a good developer or just starting out.
  • You're scroll jacking the interface. See previous point.
  • You're creating a WordPress site and just discovered themes and plugins. See first point.
  • You're viewing a demo showing how JavaScript animations are affected by jank.
  • You're using IE6 with 40 different custom search bars while running BonziBuddy.

 

ZsuckhV.jpg?v=1

 

 

So all those demos and articles that talk about the performance benefit of WAAPI are not entirely true. WAAPI only performs better when it's being demonstrated using cherry picked conditions. There are like several hundred different CSS properties that can be animated. To say that you should only animate transforms, alpha, and a couple filters is crazy! That's sounds more like a coding challenge. And what about SVG? Should we just ignore that all together? I think not.

 

 

 

  • Like 7
Link to comment
Share on other sites

1 hour ago, Jonathan said:

That is weird why they named it Houdini. There is already a 3D software named Houdini, that is a 3d morphing program used in visual effects in various blockbuster movies :)  For example in the movie Fight Club, Houdini was used in the awesome airplane cabin scene.

 

Hehe. Searching for CSS Houdini doesn't bring up a lot of results, so after a few pages, most of the results are about that, and after that, the results are about the magician. And that's where the name comes from. It allows you to tap into the magic of Styling and Layout on the web.

 

@Dipscom

 

Before I forget, here's a good web worker demo, which is just like a worklet. Get the number of objects up to 5-10,00, and then toggle the workers to see the performance difference.

 

See the Pen gaqJJg?editors=0010 by SeanMcBeth (@SeanMcBeth) on CodePen

 

 

@Sahil I saw your question. I was going to respond back later on with some more stuff.

 

 

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

Hey Blake,

About 30 seconds into your previous post (exaggerated demos of waapi vs gsap) I had pulled out the Ban Hammer and was giving it a nice polish;)

 

Great job debunking the myths of the gurus!

 

I can't help but laugh and cry a little when I hear people say "you should only animate transforms and opacity". 

 

Normal person: "I'd like to animate the width of this.."

Guru: NOOOOO, STOP! It will cause a repaint! Your site could crash, especially on mobile devices!

Normal person: "I just ran an augmented reality demo on my phone where a horde of zombies exploded in front of me"

Guru: You don't understand, laying out a grid with different sized fonts is EXTREMELY processor intensive.

 

 

  • Haha 7
Link to comment
Share on other sites

On 12/14/2017 at 9:14 AM, Jonathan said:

@OSUblake .. I don't know lol, your talking about all this "magician" stuff and "magic of Styling and Layout".

 

For shame.. we used to burn people at the stake for such talk, or dunk them in water and see if they float, cuz as we all know, magical witches don't float (nor do real people) :)

 

Every time I hear somebody talk about burning witches, I always think of this scene from Monty Python. :lol:

 

 

  • Like 1
  • Haha 2
Link to comment
Share on other sites

On 12/14/2017 at 9:21 AM, Carl said:

Hey Blake,

About 30 seconds into your previous post (exaggerated demos of waapi vs gsap) I had pulled out the Ban Hammer and was giving it a nice polish;)

 

Great job debunking the myths of the gurus!

 

It's always fun to lead the reader on, validating their opinions, and then pull a 180 on them! I should find a pro-WAAPI place to post that on. :P

 

For even more fun, check out this tweet. 

 

https://twitter.com/shshaw/status/941767533610323968

 

See the Pen BJNRYv by shshaw (@shshaw) on CodePen

 

 

 

 

  • Like 2
  • Haha 1
Link to comment
Share on other sites

On 12/14/2017 at 12:23 AM, GreenSock said:

Houdini looks really cool, Blake. Can't wait until that stuff is actually usable widely. I always get sad, though, when it dawns on me that it'll probably be years and years. When it becomes more realistic, I'd love to kick ideas around with you regarding Houdini in GSAP. [Setting a reminder for mid-2019 ;-)]

 

I'm going to post more stuff about Houdini, but the reason I'm doing this is to be a little proactive so what we don't have to wait until mid-2019. Features get added based on popularity, so the word needs to get out. But more importantly, you can use your influence as the author of a popular animation library to help shape Houdini.

 

For example, one problem I see in the future is that requestAnimationFrame is capped at 60fps, and there are no plans to change that because it will break some existing sites. This means that JavaScript animations will only be able to run at 60fps regardless of the user's display, while CSS animations will be able to match any refresh rate, so 120fps+. And then you have WebVR, which is supposed to run at 90fps.

 

So JS needs a timing mechanism than runs faster than rAF, which might be possible with the help of worklet. I don't know what that might look like, but it should definitely be explored.

  • Like 2
Link to comment
Share on other sites

Yeah, feel free to make a specific list of proposals and maybe we can tag-team. I must admit I haven't had a wonderful experience with getting spec authors to budge on much of anything, so I'm not generally inclined to burn much energy in that direction but if you think there's hope I'll certainly consider jumping into the ring more. Most of the time, though, I spend my time looking at current browsers (and the last few years' worth) to ensure everything works well. I live more in the current world trenches rather than the distant future's panacea. :) 

Link to comment
Share on other sites

37 minutes ago, GreenSock said:

Yeah, feel free to make a specific list of proposals and maybe we can tag-team. I must admit I haven't had a wonderful experience with getting spec authors to budge on much of anything, so I'm not generally inclined to burn much energy in that direction but if you think there's hope I'll certainly consider jumping into the ring more. Most of the time, though, I spend my time looking at current browsers (and the last few years' worth) to ensure everything works well. I live more in the current world trenches rather than the distant future's panacea. :) 

 

Hehe. I can appreciate not wanting to get involved with a spec as it's the equivalent of dealing with the government. It takes 10 years to come up with something, and the end result looks nothing like what you originally proposed. 

 

I need to do some more investigating, but it seems like a worklet for doing purely JS-driven animations could be possible. The current draft for the animation worklet describes something close to that, but is designed to work with a WAAPI/CSS timeline.

 

Here's the message that led to what is now the animation worklet, and some of the problems with running animations on a different thread. 

https://lists.w3.org/Archives/Public/public-houdini/2015Mar/0020.html

 

  • Like 2
Link to comment
Share on other sites

18 minutes ago, Carl said:

Yeah, the GSAP "controlled" CSS Animation was certainly a bit un-orthodox. Doubtful we'll be promoting that feature any time soon :mrgreen:

 

As seen in my second GSAP vs WAAPI demo, it's better to let GSAP deal with the jank. Animators want consistent handling of jank first and foremost. :lol:

 

  • Like 2
Link to comment
Share on other sites

  • 2 years later...
On 12/14/2017 at 4:09 PM, OSUblake said:

 

Hehe. Searching for CSS Houdini doesn't bring up a lot of results, so after a few pages, most of the results are about that, and after that, the results are about the magician. And that's where the name comes from. It allows you to tap into the magic of Styling and Layout on the web.

 

@Dipscom

 

Before I forget, here's a good web worker demo, which is just like a worklet. Get the number of objects up to 5-10,00, and then toggle the workers to see the performance difference.

 

 

 

@Sahil I saw your question. I was going to respond back later on with some more stuff.

 

 

@OSUblake

I was thinking to measure how it could affect performance!
you really did a good job! thanks a lot!
I was looking for that!

 

I have 2 queries in mind:

1- Will it be possible or useful running gsap on the web-worker?
2- How to optimize SVG to boost the performance of the client side?

Link to comment
Share on other sites

11 hours ago, Nasr Galal said:

How to optimize SVG to boost the performance of the client side?

Read this.

 

11 hours ago, Nasr Galal said:

Will it be possible or useful running gsap on the web-worker?

I don't believe it'd help much in most circumstances because the primary performance cap is the rendering which can't be done in web workers as far as I know. If you had a lot of calculations or something then maybe it'd help.

  • Like 2
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.
×
×
  • Create New...