Jump to content
GreenSock

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

danehansen

Members
  • Content Count

    42
  • Joined

  • Last visited

Community Reputation

5 Newbie

About danehansen

  • Rank
    Advanced Member

Recent Profile Visitors

3,996 profile views
  1. just found something that applies to this topic that i thought i would share here. it appears that when tweening a parent element's css variable to tween multiple children, it causes repaints on each child. where doing the same tween on the children themselves can cause no repaints. check out the following jsfiddle example with your dev tool's paint flashing turned on and see the difference between the two: https://jsfiddle.net/k95c51yy/3/ kind of a bummer but oh well.
  2. i think the performance concerns are probably related to the babel side of things? those are definitely to be considered. babel does not always convert stuff into vanilla js in the most efficient manner. but utilizing webpack does not mean having to use babel. you can still write vanilla js that wont be touched. in this case webpack would only be adding a very thin wrapper to handle the imports/exports. also as far as moving to new build systems (browserify to webpack etc...) if you had jumped on browserify, you wouldn't need to rewrite any code, with the possible exceptions of the import/expo
  3. i suppose i will jump back in here too. i wanted to include some other reasons to move to a traditional build system (doesn't HAVE to be webpack, but might as well be webpack) 1. collaboration/forking - i know you guys dont accept PRs because you maintain the code yourself, but having a more traditional build can allow people to help try stuff out, which you could in turn decide whether or not you want to incorporate. also could allow users/businesses to fork the repo and use their own flavor. currently the git repo and what is installed from npm appear to be unrelated so it is quite diff
  4. yes, this does this trick! but when implementing i noticed that on a .fromTo tween that i need the modifier on both objects passed in. is that expected? and if so, why?
  5. 49, not 59. at my job we ship our product in chromium v49, and yes, applied multiple times like you said at first. the reason for not applying the tweened css variable at the root is that i want it scoped to each element. as far as the performance/timing issues, its more difficult to see in my jsfiddle, but i was able to see some lagging when clicking around a bunch. in implementation on the project it was much more obvious because of the weight of the application. i wouldn't suggest always calling `removeProperty`, but on the first css variable tween it could probably be determined if it were
  6. i attempted to upgrade gsap version at work and implement a tween of some css variables and immediately found an problem in chrome version 49 which i have personally already bumped into, and not sure what other browsers this could also branch to. to be clear, this is a problem in chrome, but the workaround is easy enough you might want to incorporate it into gsap. in chrome 49 when calling `setProperty` on a css variable that is already declared, rather than replacing the old value, it is added to the element. so throughout the course of a tween, a css variable is then defined on an element ma
  7. ah back to the ol' alias trick again =(
  8. this would work fine locally but in a large team, not so much. i would still want to install the `gsap` npm package and then probably included the bonus files with the project's source.
  9. having trouble with CustomEase in webpack as well. if i'm installing gsap through npm, then i need to have the special plugins in the projects own source, and in the case with CustomEase its throwing an error that CustomEase cannot resolve module TweenLite. if someone has a license to use the special case gsap plugins, they're still gonna want to install the majority of gsap through npm.
  10. this is great, i was just gonna post on here asking about css variable support. any word yet if it hinders performance? on one hand, we can tween the properties of many items by changing one variable, but on the other hand it utilizes window.getComputedStyle and style.setProperty, which might offset any savings.
  11. this is great. i remember reading about this technique back in the day but totally forgot about it. thanks.
  12. when using `BezierPlugin` to tween something along a bezier curve, you are able to add a `type` of values `thru`, `soft`, `quadratic`, or `cubic`. is there a way to get a curve of similar results when getting bezier objects from `BezierPlugin.bezierThrough`? i understand that there is the `curviness` argument, but i would really like to apply `soft` to my data i am getting back. thanks.
  13. there appears to be an issue with the ordering of gsap related imports in webpack. i had seen and mentioned this in one of our earlier threads, but was finally able to narrow down when it happens. i'm working on something where i'm trying to utilize several classes from the gsap library, and noticed when attempting to introduce TweenMax that it logs out as an empty object, and therefore i am not able to utilize it. TweenLite is also in the project, as well as BezierPlugin. the problem appears to be resolved if TweenMax gets imported before BezierPlugin, but hopefully this could be rectified as
  14. ya i'm liking the last option, but i'm thinking of an alteration that i will make all these canvas properties getter/setters on one object, they all flag as dirty for the object to render, then the object has one additional render method that the parent, who owns the timeline, runs onUpdate. then i dont have to mess with adding/removing a listener to TweenLite's tick. thanks!
  15. I forgot to clarify, this TimelineLite instance may also include portions where no canvas related properties are being tweened, and therefore I do not want to call the draw method unnecessarily, which is why I am not putting the onUpdate param on the TimelineLite instance itself, but instead just on the TweenLite instances of canvas properties.
×