danehansen

im having a hard time figuring out what is going on when calling gsap.getProperty() by looking at the source code, but i assumed that under the hood that it would be calling element.getBoundingClientRect(), which in theory shouldn't be necessary if there is someplace else to get the value without calculating it off a dom element. am i correct or wrong?

in a scenario where i want to tween a dom element's position, but i would like to also make some caclulations on that current position onUpdate, is there a way that i read that dom element's current position without having to get it off the styles of the element or any of its getters?

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.

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/export statements. if/when webpack goes anywhere, it will be because something else solves that problem better and you will still be able to leave almost all code untouched. the rewriting would just be in config files for the build process.

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 difficult to be able to alter the gsap code and have it installed via npm. 2. ability to more easily get away from the global scope. its unavoidable for users installing via script tags, but for those using npm, it is sometimes quite important to keep the global scope clean. it can become a security issue. the duality of globals for script tag importers and privates for npm users can be solved with UMD, built into webpack. 3. your source code will be simplified and easier to understand if you let webpack handle the dependencies rather than various other hacks. 4. the longer these difficulties exist, the more open to the danger of a major tech company (google, facebook, etc...) putting an entire team of engineers on the task of creating an open source/free animation library that would almost certainly be immediately adopted throughout the tech community, and in turn be adopted by casual users. if your library is easy for everyone to implement and doesn't make anyone have to compromise, no one will want to re-solve the problem. 5. javascript changes so fast, and its always good to keep up with latest common practices for your own knowledge/experience.

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?

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 necessary and then called or not called from then on.

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 many times, which the latest one is always the overriding winner, but there seems to be some performance hits associated with this as well as timing effected. teh known workaround is to call `removeProperty` before calling `setProperty` again. go ahead and try out the jsfiddle in chrome 49 and watch the inspected markup as you click around.

ah back to the ol' alias trick again =(

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.

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.

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.

this is great. i remember reading about this technique back in the day but totally forgot about it. thanks.

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.

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 it is confusing to users, and in large organizations some codebases are subjust to strict linting rules that would prevent the reordering of imports. including zip file of simplified project with comments. Archive.zip

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!

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.

Lets say I have a complex TimelineLite instance, which is maybe tweening some DOM elements' CSS properties but also is tweening some pure JS properties which are used in drawing on canvas. Any time one of those canvas related properties updates, I want to call a function that redraws the canvas, but if some of those tweens are overlapping, I want to be sure that I am not redrawing the canvas more than once per tick. Is there a baked in way to achieve this? Or is my best bet to have the drawing method be a pre-throttled method? Cons to that would be that the throttling is then set at a hard ms time, rather than at the current requestAnimationFrame rate.

nice thanks!

ok that makes sense. part 2 here... i have a .fromTo in there that i want the element to have the from value initially, but what happens is that it isn't applied until its delayed tweening starts. example: https://jsfiddle.net/37LL1atx/3/

that is really strange, given that all the documentation on `drop-shadow` shows the params in that order, but overall the reason for this break makes sense. it seems like with what you have said that flipping the order now with 1.19.1 would fix the problem, but it does not. is that expected?

ah thanks! p.s. the linter i have been subject to for the last 2 years forced me to write code like that so its what i'm used to right now =/

`drop-shadow` filter doesn't appear to work like the other filters. it seems to flip the color to the first value. https://jsfiddle.net/dwLxLes7/1/

i'm trying to set an intro animation for a component, and want parts to be hidden at the beginning of the animation. the goal is to have the component's css have nothing to do the animation so that when its done, the markup and styling looks as if we didn't use a transition. starting a TimelineLite instance with setting some instances to `visibility: hidden` seems to not have any result. a hack i have found to fix it, which i don't like, is to set the progress to 1 and then back to 0. i've included a jsfiddle link: https://jsfiddle.net/37LL1atx/1/

hey wondering if there is a simple way to adjust where an enclosed path is drawing from, using this plugin. i'm assuming its starting from the beginning point of the path, but when output from illustrator or such, we dont always have control on where on the object is going to be defined as the beginning or end of a path. so for instance if i have a polygon and out of the box the outline draws in starting at 12 o'clock and fills in until its enclosed, what if i wanted the line to beign at 3 o'clock or something else? thank you.