Jump to content


  • Posts

  • Joined

  • Last visited

BowserKingKoopa's Achievements


Newbie (1/14)



  1. Hi Rodrigo, I'm currently using the plugin I linked (https://github.com/hzdg/gsap-react-plugin) with the newest version of React without any problem. It's a really simple plugin, maybe 50 lines of code. All it does it redirect all GSAP animations that target a React component through the React setState mechanism. So while I'm not the author of it, I think there hasn't been any updates because it's done. It's the opposite of the approach you mentioned: "not piping anything GSAP related through the state to avoid rendering the React component on every GSAP tick". I tried that at first and quickly got tangled up. It was hard. I found that in my game I often needed React and GSAP to manipulate the same properties and trying to sort it all out became a source of many weird bugs. So now I'm piping EVERYTHING through React (using that plugin). So far so good. And it lets me keep my mind in "React mode".
  2. The thing about React is not performance gains. Sometimes you get some because it knows all the hacks and tricks and minutiae of DOM manipulation (as does GSAP). But that's not the thing. The thing is Immediate Mode (yay!) vs Retained Mode (yuck). React lets you code as if the Retained Mode DOM was, in fact, Immediate Mode. Immediate Mode is such a big win I'd trade performance for it. I'd trade GSAP for it (though I don't want to). I'd trade almost anything for it. It's that big of a win. It's the proper API for building a UI. The performance hit for putting GSAP on top of React hasn't proven to be noticeable in my current game project. I'm using https://github.com/hzdg/gsap-react-plugin which pipes all my GSAP animations through React's setState mechanism. I've suffered no noticeable performance hit for doing so. (It might not even be slower. Probably depends on who is better at DOM manipulation, GSAP or React). So I'm quite happily using GSAP with React. I'd be happier if GSAP had a React Component API though, which is what this post was about.
  3. Nothing's really breaking. There's nothing to really fix. (Except your entire way of thinking. Ha! React!). GSAP and React just don't play together well. This blog post does a good job of describing the problem as well as proposing a good example of a solution: https://fabric.io/blog/introducing-the-velocityreact-library Hooking into React lifecycle methods to fire off GSAP calls is a hack. What the React developer really wants to do is describe the animation declaratively in the Render method using React components. The linked blog post shows a possible way of doing that that looks like a good start to me. It's more like CSS animations where you say 'when this property is animated do it like this'. Think of it as us wanting GSAP in another language, the language being React Components. Look into React. The Kool-Aid tastes great! Read that blog post. It presents a nice idea of what animation components might look like in a React style.
  4. The problem is fundamental. Imperative GSAP code doesn't fit well with declarative React code. The problem isn't specific to GSAP. React does not have a good animation story at the moment. This is something I hope GSAP might address in the future. The blog post I linked describes the problem well: "React and animation don’t actually play well together at first. There’s an impedance mis-match: React’s power stems from abstracting away the state transitions in your UIs (it does them quickly and correctly, enabling the declarative paradigm we’ve come to love), while animations live entirely within those state transitions." and "To integrate smoothly with React’s declarative nature, we’ll need our animation behavior to be fully described by the output of our render methods: a desired end state." https://fabric.io/blog/introducing-the-velocityreact-library Their solution was a set of React components that let them create animations in a React friendly way. Something like that for GSAP would be amazing. GSAP should embrace React.
  5. I'm currently using GSAP in ReactJS (via https://github.com/hzdg/gsap-react-plugin). But it's difficult because it's an awkward mix of functional React code and imperative GSAP code. And you have to jump through hoops to make sure GSAP doesn't interfere with the React rendering. We desperately need something like this: https://fabric.io/blog/introducing-the-velocityreact-library -Ryan
  6. So it's definitely a Chrome thing. Other browsers look good for me as well. Using an img tag instead of a background image is a bit of a pain in the actual game but still it's something I might be able to get working. Thanks so much for your help.
  7. Except if I do the same transform using CSS transitions it's silky smooth. So it's not beyond the capability of the browser by any stretch. It has to do with the way Draggable is doing the animation. The demo you made with the smaller image is still pretty choppy. I still think something weird is going on in Draggable.
  8. I have a container and inside the container I have my "game". I drag the game view around using Draggable. I tried to implement a zoom feature and found that when I animate the Scale of the Draggable it is very slow and choppy, as demonstrated in my codepen. The same zoom feature implemented with CSS Transitions is smooth as silk (but I can't use that in my actual game because it interferes with Draggable. They fight over the transform). Can you help me figure out why this animation is so slow and if there's a better way to do this? Thanks. -Ryan Edit: The problem is most apparent in Chrome.
  9. Overwrite: none is not behaving how I imagined it would. In my codepen example I imagined that the second tween would be ignored because the first tween is already animating the element's "width". Instead it seems like the first tween is being overwritten despite overwrite being set to "none". Am I misunderstanding overwrite? Is there a way to accomplish what I want (where the second tween would be ignored because another tween has already 'claimed' the right to animated "width"?) http://codepen.io/anon/pen/BoJMvw Thanks for any help. -Ryan
  10. This is working perfect for me. Thank you. However, it seems to be working without me having to call update(). When is calling update necessary? Updated codepen: http://codepen.io/anon/pen/byuor
  11. What is the best way to control a Draggable element's scroll position programmatically? I'd like to be able to explicitly set the draggable's x, y position from code. Setting the draggable's x and y properties doesn't seem to do anything (the docs list them as 'read only'.
  12. How can I tone down the speed of the 'throw' when I drag my element? Right now a little flick sends the element flying across the screen.
  13. Is there a way to specify lagSmoothing on a per tween basis? It seems like one global setting isn't flexible enough. I'm building a game. Most animations correspond to 'real' things happening in the game world therefore accurate timing is important. They can't ever 'pause' when someone minimizes the window or lags a little bit. However other animations, more eye-candy in nature, might benefit from the lagSmoothing feature.
  14. I turned off lagSmoothing and it fixed my problem. This behavior still seems like a bug to me. Smoothing out lag is a great feature, but a minimized (or otherwise invisible) window is not lag. Having an animation pause when the window is invisible is, I imagine, rarely what is expected or desired.
  15. Here's a sample: http://codepen.io/anon/pen/DwGoI Start the animation, then minimize your browser. Go get a cup of coffee, come back, show the window again, and the animation will pick up from where it left off when you minimized the window. I need the animation to keep running even when it's not visible.