OSUblake last won the day on July 12

OSUblake had the most liked content!


  • Content count

  • Joined

  • Last visited

  • Days Won


Posts posted by OSUblake

  1. Your SVG is almost 4,000 lines of code with 10,000 DOM nodes. A lot of it doesn't even look important, like all these empty path coordinates.


    <path fill="#C9D0D2" d="M637.1,397.9C637.1,397.9,637.1,397.9,637.1,397.9C637.1,397.9,637.1,397.9,637.1,397.9



    You might want to run your SVG through an optimizer, like SVGO.




    • Like 4

  2. 1 hour ago, francis789 said:

    Despite starting all objects from the coordinates, they seem to come from different places...


    Remember this?



    You should remove transforms from anything you want to animate as it might cause problems with scaling and rotation.



    All your images start off scaled from a different origin, so your transform origin is throwing everything off.





    • Like 4

  3. 42 minutes ago, iDad5 said:

    Would be interested in that answer too.


    The whole types thing is screwy, but there are 2 different versions. 


    @types/greensock is the old version which has the conflict.



    @types/gsap is the newer, but still incomplete version. It shouldn't have that problem as the Animation class is now inside a "gsap" namespace.



    • Like 1

  4. A <g> element has no real position or size. It's defined by its children. That's why positioning everything at 0,0 and using the center works so well. If any children of a <g> cause the position or size to change i.e. its bounding box, everything will remain anchored around the center point.


    And you can't drag a nested <svg> element because transforms won't work on it, so you'll still need to use a <g> element somehow.

    • Like 4

  5. 30 minutes ago, admin web said:

    Thanks for the reply.

     am trying as per your code but still svg not drag along the path.


    It's much easier to work with SVG when elements start at 0,0 coordinates, which is what my demo assumed. The patch should be in the very top-left corner, but it's not. Fix that and it should work just fine.





    Also, the line element doesn't have to be a real element. You can plug in your own values from your data for x1,y1,x2,y2 if you want.

    • Like 2

  6. Are you sure waiting for the page to completely load is a good idea? It looks like you have a bunch of images, and on a slow network the user might be staring at a blank screen for a while.


    Anyways, here's a pattern I sometimes use. I hide stuff until the DOM is ready by putting an "unresolved" attribute on elements to prevent FOUC. The unresolved name is arbitrary, so you can use whatever name you want.


      [unresolved] {
        display: none;
    <body unresolved>



    From there I check the readyState of the document to determine when to initialize the app. Notice the difference between the "DOMContentLoaded" and "load" events. I'm usually only interested in when the DOM is interactive, so I don't worry about all the images being loaded.






    if (document.readyState === "interactive" || document.readyState === "complete") {
    } else {
      window.addEventListener("DOMContentLoaded", resolve);
    // Initialize your app
    function resolve() {
      TweenMax.from("#content", 1, {
        opacity: 0,
        y: 50






    • Like 5
    • Thanks 1

  7. x1 is a property of a line, but it's value is set on a different path/object.


    this.line.x1.baseVal.value = 150;


    Definitely not a convenient value to animate. Try using the AttrPlugin.



    TweenMax.to(this.line, 1, {
      attr: {
        x1: 150
      stroke: "red"


    Updating to the latest version of GSAP wouldn't hurt either.




    • Like 3

  8. 28 minutes ago, Carl said:

    @chiho this is the same question you asked here and Blake already invested time trying to help.


    Not only that, but the source code of that three.js demo does the same thing I described. Sine.easeInOut is Math.sin(). The 3d perspective isn't important. Look at how the init and render functions work.

    Demo - https://threejs.org/examples/#canvas_particles_waves

    Source - https://github.com/mrdoob/three.js/blob/master/examples/canvas_particles_waves.html



    For a parallax effect, you can scale your values by some ratio, like in this post. I'm guessing @Shaun Gorneau did something similar.




    • Like 4

  9. 17 minutes ago, jodriscoll said:

    Baby steps, but I am aware and it's something on my list of pursuing for additional improvements as well. If you have any recommendations, I'm all ears :)


    You can use the intersection observer for scrolling, and there are polyfills for IE and Safari. It's asynchronous, so some of your code might be deferred under heavy load, but performance should generally be better. 




    17 minutes ago, jodriscoll said:

    I've implemented the approach you suggested and noticed that any property which can be managed through matrix3d() is combined into a single definition, which I was unaware of until now! Thanks for the recommendation and I'm already noticing an improvement in the scrolling experience.


    Yes, check out the docs for the CSSPlugin. That's where most of the magic happens if you're animating the DOM.



    Also, using CSS Containment can help with reflows/repaints, but browser support isn't that good at the moment.


    • Like 4

  10. 14 minutes ago, jodriscoll said:

    As most of you may know, animating the width of an element does not leverage the GPU, causing a reflow of the DOM, which is bad for performance,


    I hope you realize that getting the scroll position causes a reflow, so using ScrollMagic can negate some of those benfits. 🤔



    And scaling isn't as optimized as most people like to think. The browser can rasterize the content, limiting the amount of scaling you can do before it starts looking like crap, or it can repaint the content on every animation frame. Using will-change will cause rasterization. 




    To scale x, simply scaleX.


    .to( animate.down, 1, {
      x:            animate.neg,
      y:            animate.pos,
      scaleX:        0,
      repeat:       1.25,
      ease:         Sine.easeOut,
      yoyoEase:     true
    }, "together" )



    To prevent squashing/stretching of children during a scale animation, you can apply a counter scale. 





    • Like 3

  11. Not sure I understand what you're asking. Take a look at this thread for some of the theory behind a wave animation. It works the same for canvas.




    Sine is cyclic. It doesn't matter what number you put in, you will always get back a value between -1 and 1. You can use that knowledge for a delay or progress value in your animation.


    for (var i = 0; i < 50; i += 0.1) {  
      // This will always output a number between -1 and 1



    See the ticker loop in this PixiJS demo. It's not using GSAP, but it's using sine to create a wave. Same concept. It's just offsetting the start time of each of point.



    • Like 3

  12. Another approach that requires a little more work, but is more flexible. It finds the closest point on a path, and does not require a proxy element.




    A couple threads on the technique.





    • Like 5

  13. You can always use promises for complicated async behaviors. Async/await works in all modern browsers, and there are plenty of polyfills for older browsers,


    button.addEventListener("click", async () => {
      await new Promise(resolve => animateAsync(resolve));
      // Starts halfway through the first animation
    function animateAsync(resolve) {
      var tl = new TimelineMax({
          delay: Math.random()
        .to(elementA, 2, { x: 500 })
        .add(resolve, 1);
    function animateSync() {
      TweenLite.to(elementB, 1, { x: 500 });




    • Like 4

  14. On 6/14/2018 at 10:53 AM, Rodrigo said:

    React's declarative nature, which is quite unique and the fact that the React team doesn't help too much in getting access to the DOM elements. In fact I've read some comments and Tweets from Dan Abramov (creator of Redux and part of the React and React Create App teams), where He declares that accessing the DOM nodes should be a no-no and that is anti-pattern. Obviously Dan hasn't done a single complex animation in His life on a React app ;).


    I played around with React and Redux once... 😝


    Too many rules and constraints, and I like touching the DOM, so I set out to find something better. That's when I came across some nice VDOM alternatives,  lit-html and hyperHTML. They're faster, more efficient, and accessing DOM nodes is perfectly ok. It's definitely worth checking out.


    Here's your simple list of elements demo using lit-html. Codepen doesn't have syntax highlighting, but there are plugins for that on VS Code.



    • Like 4

  15. On 6/27/2018 at 3:30 PM, GreenSock said:

    Does this updated Draggable work the way you'd expect for the ShadowDom stuff?: 


    It's looking good with HTML. SVG is a different story.


    An <svg> element can be made draggable, but throws an error with a bounds.

    const svg = this.shadowRoot.querySelector("#svg");  
    // OK
    // ERROR
    Draggable.create(svg, {
      bounds: this



    Trying to make anything inside an SVG draggable will create an error, regardless of bounds.

    const ball = this.shadowRoot.querySelector("#ball");  
    // ERROR
    // ERROR
    Draggable.create(ball, {
      bounds: this




    • Like 1