OSUblake last won the day on January 21

OSUblake had the most liked content!

OSUblake

Moderators
  • Content count

    3,176
  • Joined

  • Last visited

  • Days Won

    319

Everything posted by OSUblake

  1. Tweening the hue in hsl colours

    Yeah, a demo would help. One thing I noticed is that you're getting the hex value, which will look different than hsl when animating. Doesn't three.js have a .getHSL method?
  2. Throwpropsplugin not working (npm/webpack issues....)

    Awesome! That's why I was asking about what the bottom of the draggable file looked like. The github repo is structured a little different than the package hosted on npm.
  3. requestAnimationFrame vs throttle

    This will work with GSAP due to way it parses color values that are numbers. TweenLite.to(element, 1, { backgroundColor: Math.random() * 0xffffff }); Take a color like #bada55. It's rgb value is 186, 218, 85. You should be able to copy and paste that into your console to test it out. color = 0xbada55; r = ((color >> 16) & 0xff); // 186 g = ((color >> 8) & 0xff); // 218 b = (color & 0xff); // 85 rgba = `rgba(${r}, ${g}, ${b}, 1)`;
  4. requestAnimationFrame vs throttle

    I just wrote something about this. A general purpose throttle function can be useful for a lot of things, like making a bunch of ajax requests. However, the problem with a lot throttle functions is that they don't fire the callback at the end of the throttling phase, which can result in the last call being skipped. That can be really bad for like a resize. In general, using requestAnimationFrame to throttle repeating events like resize, scroll, wheel, keydown, mousemouve, touchmove, and pointermove is a good approach. I don't think a lot of people realize how fast some of those events can fire. For example, if I do a 10 finger swipe in Edge, it will fire about 15 kajillion pointerevents. It does that for a reason. To provide better accuracy when using a pen, but you definitely don't to respond to all those events.
  5. WAAPI-Powered GSAP? Unlikely

    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. 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 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. I would much rather have a general purpose JavaScript animation worklet that doesn't depend on WAAPI or DOM elements.
  6. If you need the specific index and target for whatever reason, you can do a staggered tween.
  7. Scope is what "this" refers to inside the function. Your animation will complete at the same time for all the boxes, so index is pointless. You can lookup the target on the tween. By default, the scope of a callback will be the tween, so the target will be this.target.
  8. NS_ERROR_FAILURE with TweenMax

    Yep. That's what happens in Firefox when something can't be rendered. Make sure the loading is complete before setting up any animation stuff.
  9. Throwpropsplugin not working (npm/webpack issues....)

    Yeah, that's strange. Sounds like it isn't being loaded correctly for some reason.
  10. NS_ERROR_FAILURE with TweenMax

    There's a 100% chance that you're setting display to none on something, or messing with something that can't be rendered, like an element inside <defs>.
  11. Throwpropsplugin not working (npm/webpack issues....)

    Hmmmm... I'll try and setup something later today on bitbucket and see what the problem might be. As a sanity check, trying renaming the package and everything else to something other than "gsap", like "gsap-test", and then importing with that new name. I know that will fail for the member plugins, but I'm wondering if will work for a simple import like TweenLite. import {TweenLite} from "gsap-test"
  12. SVG Motion Path Animation - Point Callbacks

    Haha I see what you did there.
  13. Throwpropsplugin not working (npm/webpack issues....)

    Hi @Tim Rijkse Are you forking the GSAP repo from GitHub? Make sure the package name is gsap, and it might be a good idea to clear your cache so it doesn't try to install the hosted version of gsap. Not 100% sure, but the problem might be the paths. Does the bottom of the Draggable.js file look like? //export to AMD/RequireJS and CommonJS/Node (precursor to full modular build system coming at a later date) (function(name) { "use strict"; var getGlobal = function() { return (_gsScope.GreenSockGlobals || _gsScope)[name]; }; if (typeof(module) !== "undefined" && module.exports) { //node require("../TweenLite.js"); require("../plugins/CSSPlugin.js"); module.exports = getGlobal(); } else if (typeof(define) === "function" && define.amd) { //AMD define(["TweenLite", "CSSPlugin"], getGlobal); } }("Draggable")); Or more like this? //export to AMD/RequireJS and CommonJS/Node (precursor to full modular build system coming at a later date) (function(name) { "use strict"; var getGlobal = function() { return (_gsScope.GreenSockGlobals || _gsScope)[name]; }; if (typeof(module) !== "undefined" && module.exports) { //node require("gsap/TweenLite.js"); require("gsap/CSSPlugin.js"); module.exports = getGlobal(); } else if (typeof(define) === "function" && define.amd) { //AMD define(["gsap/TweenLite", "gsap/CSSPlugin"], getGlobal); } }("Draggable")); Notice how the paths are different. I'm wondering if that's the issue.
  14. transform in vh units

    I was just about to bring that up. The ratio value of the tween is what you should use. Every ease has a getRatio method, which is where that value comes from. Kind of like this. var ratio = Sine.easeInOut.getRatio(tween.progress()) So the modifier functions should use that value instead of progress. var tween = TweenMax.to('.slide', 3, { x: vw(50), y: vh(50), ease: Sine.easeInOut, modifiers:{ x: function(x){ return tween.ratio * vw(50); }, y: function(y){ return tween.ratio * vh(50); } } })
  15. transform in vh units

    It should work if the animation is paused. I think it will only be evaluated at creation for immediateRender tweens. https://greensock.com/immediateRender
  16. Create a radial wipe

    Hehe. And now you know why I hate SVG arc paths. Try this. Set the start and end to 360, and tween the end to 0. Instead of messing with the internals of the getPath function, swap the start and end parameters around in updatePath function. var arc = { start: 360, end: 360, cx: 250, cy: 250, r: 150 }; TweenMax.to(arc, 3, { end: 0, ease: Linear.easeNone, onUpdate: updatePath }); function updatePath() { // clipPath.setAttribute("d", getPath(arc.cx, arc.cy, arc.r, arc.start, arc.end)); clipPath.setAttribute("d", getPath(arc.cx, arc.cy, arc.r, arc.end, arc.start)); }
  17. Create a radial wipe

    Yeah, there's no easy solution for a clip path like. Well, it's pretty easy to do with canvas, but most people aren't willing to try it. For SVG, you have to recalculate the arc paths on every change, which can be really hard to understand. I understand how they work, but still get confused by all the different parameters. https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Paths#Arcs Here's a somewhat related demo that explains how the arc paths are calculated in the comments.
  18. Scaling parent and child element

    Quick follow up. Just make sure that you use an ExpoScaleEase on both the parent and child element.
  19. Scaling parent and child element

    Turns out that animating scale is actually pretty deceiving. You can read about that and how we ended with that ease function here. The original problem was how to make an infinite zooming animation. Using a regular ease causes the scaling to slow down. Don't worry too much about what's going on inside the ExpoScaleEase function. The goal is to possibly add that as an ease to the GSAP library, so just treat it like that for now. For now, all you need to know is how to call it. The first parameter is the starting scale, and the second parameter is the end scale. TweenLite.fromTo(element, { scale: 2 }, { scale: 1, ease: ExpoScaleEase(2, 1) }); That will actually make it look linear, so I added an optional third parameter to pass in a GSAP ease to follow. // Now it will look like it's scaling with a Power3.easeOut ease TweenLite.fromTo(element, { scale: 2 }, { scale: 1, ease: ExpoScaleEase(2, 1, Power3.easeOut) }); As to why it's better, you no longer have to do this. It's kind of built into the ease. function updateScale(){ TweenLite.set(test._mask._inner, {scale : 1/test._mask._gsTransform.scaleX}); } And creating a new tween 60 times per second can degrade performance. When the browser's garbage collector kicks in, it has to find all those unused objects and delete them, which can result in dropped frames.
  20. Create a radial wipe

    Here's a demo I made. It does pretty much the same thing the demo you provided does, but uses GSAP to control the animation.
  21. Counting from 1 to millions - add commas

    Another tip, when animating numbers, set tabular numbers in your CSS to prevent jumping. Notice how the bottom number doesn't jump when animating.
  22. SVG Motion Path Animation - Point Callbacks

    @GreenSock can you explain how timeResolution works? That is something I've always wondered, but keep forgetting to ask. After thinking about your question, I remembered that SVG path elements have a getTotalLength() method. This seems to work.
  23. And an interesting thing about parallax is that it can kind of be done using only CSS. But it might require a little JS to make it work across every browser. https://developers.google.com/web/updates/2016/12/performant-parallaxing Demo from that article... https://googlechromelabs.github.io/ui-element-samples/parallax/
  24. Yes, DO NOT SCROLL ANIMATE ALL THE THINGS! Some people take scroll animations a little too far. It needs to be subtle, like that apple watch page. https://www.apple.com/apple-watch-series-3/ Performance can also be a problem with really long pages. If you inspect the elements on that apple watch page, you'll notice that they are setting the visibility of divs with the .subsection-content class to hidden when they are out of view. That can drastically improve performance.
  25. Not sure why the polyfill doesn't work. I didn't test it out, but it says it's compatible with IE7+. Keep in mind that the script I wrote is very simple, and hasn't been battle tested, so use at your own risk. If I were to make it into a scrolling library, there's a lot more stuff I would want to add to it. Unfortunately, I currently don't have a lot of free time to devote to making a full-blown scrolling library like ScrollMagic. Well, unless somebody paid me to do it. I can always make time for that.