Jump to content


  • Posts

  • Joined

  • Last visited

imdavidmin's Achievements

  • Week One Done
  • One Month Later

Recent Badges



  1. Yep that's also the plan. The performance measuring would help to establish the default setting.
  2. Jack: *writes the whole function for some random from the internet*, "Does this help?" You absolute legend you.
  3. Either way we are making assumptions - of course we can use screen size to turn off for mobile, but some mobile devices are good enough to run the animations. Having some way to measure, even if not guaranteed accurate, just adds one more data point to make a decision on whether to turn off animations or not. It's a virtual machine, so it's very much a special edge case that is unlikely to ever happen to real users. Because there's no GPU pass through, even switching windows animation by the system ramps up CPU usage to near max for a second. A more realistic scenario is indeed on a lower end mobile device or on a really old machine. Agreed on reducing animations on mobile, but some minimally animated elements still are important UX wise to make it feel more like a native app. But of course, that can't come at the price of lagging UI, which will then be more harm than benefit.
  4. Hi, Is there a special / approved way of measuring animation performance on the client? I would like to measure if the animation has lagged vs specified duration, or if greensock was being clever under the hood and skipped frames to optimise the animation. Currently I'm using a onComplete call within gsap.to to print the end of animation time, and comparing that to a time from just before the animation was called. This way I'd be able to turn off animation effects automatically across the site based on some initial test, for slower performance devices. One extreme edge case was when I opened a web app in a virtualised macOS machine that did not have GPU passthrough, so simple transform animations would freeze the entire machine. Would avoid having these problems by running a small transform animation test for a few ms duration to see how it performed, then decide on the animations for rest of site. EDIT: The timestamping method doesn't work well for performance measurement - testing shows the elapsed ms from before gsap.to() to onComplete call could be less than the duration specified in gsap.to(). EDIT2: For anyone having the same experiment with a virtualised machine for dev environment, the guest OS / Safari doesn't freeze or drop frames as per the fps measuring function given by Jack below. It's likely about how VMware renders the graphical output of the guest OS back to you on the host OS that freezes / drop frames.
  5. Hi, Thanks Jack. It does fix the quicksetter problem to specify units. Still it's a weird thing because it seems when I don't specify units, it still does something in the background. I've recreated this scenario in codepen: A Pen by imdavidmin (codepen.io) You can see that on click, the event handler uses the QuickSetter to move the div by 300 px. Nothing shows on screen. But when you resize the window, the gsap.to() animation with +=10 x starts from 300px, meaning (maybe?) quickSetter has worked, just not rendered. If you comment out qs and uncomment the .set() method, it works as expected.
  6. Hi, Is gsap.quickSetter intentionally not triggering render updates for React? I have a div that I am moving when the window resizes, and am calling the quickSetter to set 'x' in an event listener. I see no changes when the quickSetter is called, but can see the value for the translate x has changed when I make another update using gsap.to with relative values. Using .set() to replace quickSetter will update the page when the window is being resized.