Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...

ReedBE

BusinessGreen
  • Content Count

    6
  • Joined

  • Last visited

Everything posted by ReedBE

  1. It does! I’d completely disabled tree shaking in my tests, so it is indeed the lack of a global PIXI object that was the cause. I hadn’t thought of modifying _gsScope before. Thanks, Jack!
  2. Hi, I am posting here because I am facing a somewhat similar issue with the PixiPlugin. I’m using webpack to import both TweenMax and the PixiPlugin: import * as PIXI from 'pixi.js' import { TweenMax as TM, TimelineMax, PixiPlugin, Power2, Power3 } from 'gsap/all' PixiPlugin is well defined but, whenever I try to use it, I get this error: Cannot read property 'DisplayObject' of undefined This line seems to be the problem in my bundle: if (!target instanceof _TweenLite_js__WEBPACK_IMPORTED_MODULE_0__["_gsScope"].PIXI.DisplayObject) I should clarify that, unlike OP, I’m trying to animate a PIXI DisplayObject (in my case, a PIXI.Container()). Import the umd version of the plugin doesn’t seem to help. I’m guessing it might have something to do with webpack, but I can’t quite put my finger on it. Thanks! PS: I should note that I’m using GSAP 2.1.2 and Pixi 5.0.0-rc.2. Downgrading Pixi to Pixi 4 didn’t help.
  3. Thanks for your examples. To be honest, I never thought the lack of stability of clip-path animations was in any way related to GSAP. In fact, I’ve already used the AttrPlugin to achieve such animations. What I’ve witnessed on some projects, however, is crazy unwanted behaviors from the browsers themselves. Your first pen, for instance, is pretty janky in desktop Safari on a retina display. I don't blame GSAP at all, I know this is on Safari. As for Chrome, when I say I’ve witnessed crazy behaviors, I do mean crazy behaviors: This, for instance, is how I saw Chrome handled a particular SVG-based clip-path animation a few months ago. The bits of content you see on the right-hand side, by the way, belonged to another tab I had just closed. As you said, clip-path is still listed as experimental, and I came to the conclusion that it was for a good reason.
  4. Thank you all for your answers. To get back to Jonathan though: as I said, I know the clip property is a goner, but I really do feel like clip-path isn’t quite there yet. Besides being unsupported by the latest versions of IE and Edge (which already makes it a no-go in my case), I’ve experienced terrible performances with it in Safari and atrocious random graphical glitches in Chrome when animated via an inline SVG, which you kind of have to do if your want to handle Firefox as well. As much as I’d love to be able to use clip-path for mask animations, I think there’s a reason why most heavily animated websites still use clip when a canvas-based animation is not an option.
  5. Hello there, I’ve just updated an ongoing project that makes use of clip: rect() animations to GSAP 1.18.3 and it seems that said animations no longer work, on any browser. Clipping values are properly set, but they are now changed instantly regardless of the wanted durations and easings. 1.18.2 seems to work fine. Is that on purpose? I know the CSS clip property has been set to be deprecated for a while, but given the poor browser support of clip-path, its so-so performances and its downright unstable behavior at times, I feel like clip’s days are not quite over yet.
  6. Hi everyone, I can confirm that Chrome 49 on both Windows and OS X seems to have altered the way elements with background images perform when animated. I’ve been working on our studio portfolio these past few weeks and Chrome 49 has rendered a pretty heavy animation that was jank-free before completely egregious. Switching background images to manually-positioned <img> tags helped me get back to 60fps glory. That being said and even though this isn’t such an issue in our particular case, I can’t help but think this would be a complete nightmare semantics-wise if Google doesn’t fix it.
×