Jump to content
GreenSock

Friebel last won the day on December 24 2018

Friebel had the most liked content!

Friebel

Members
  • Posts

    77
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Friebel

  1. Friebel

    Happy Tween Year!

    This is no animation. This is a still frame from a 5,5 hour long animation I am currently building with all kinds of variations of the Greensock logo. Be patient. It will probably be finished in december 2039! I'll post a follow up in this thread when it's finished. Crazy particles will be in it! For now, the best for everybody for twenty ninetween! May all your wishes come true, you all have a great timeline this year! Love & Ease!
  2. Friebel

    Happy Tween Year!

    Happy Tween Year @GreenSock Jack! [edit] And ofcoarse also the best for 2019 for every other greensocker here! Spread the tweens!
  3. @OSUblake There happened to be an issue with the terser npm package (just for people that don't know; terser is the 'new' uglifyjs also webpack is using/will be using). That issue is fixed now and helps a lot mangling the webpack bundle. There's still a little issue in mangling some constructions, but the creator of terser now fixed the dom mangle problems and perhaps we can tackle thisone later too so mangling finally works! I would expect a lot of developers are using these functionality, but guess I was wrong. Thanks for trying to help!
  4. Have nice days everybody. Enjoy! Tweening home for Christmas! ? (I was about to upload a nice Christmas image, but am only allowed to upload 501.76kB (huh?). So use your imagination and think of the nicest picture of somebody on the road, full of snow, with you on the steering wheel, driving home.... uh... on a Greensock tween... so let's make it green snow or something. Well, enjoy! ?‍?‍?
  5. Totally agree. Pretty fuzzy sorry, maybe I should have said this thread can be closed. This is something I have to find out for myself now. Sorry for being so fuzzy. I'm in some nasty private situation now, so my head was a little fuzzy yesterday. I'm looking for a button to close this thread, but can't find it. Anyway, this one can be closed. I'll rename the title. Thanks again everybody here for trying to help.
  6. Thanks @OSUblake. My questions was pretty dumb and I posted it too soon. Thanks for bringing to my attention that everything inside svg is absolute. That's something I know. My problem here is in fact that the graphical software (in this case Affinity Designer for a project I'm working on now) is not (always) using transforms to position groups, but applies all positioning to all sub-objects of a group. That makes it pretty difficult to animate in Javascript, because then we have to position all children instead of the group. So, guess I wasn't really thinking when posting this question. Maybe a solution to this 'problem' would be to output transforms on groups again. But problem is that Designer is not always that nice in it's svg output, so it wouldn't surprise me if they still output pre-calculated positions on the group-children instead of letting the children stay on their zeros and just applying transforms to the group. But I will look for that. I was also thinking about using something like 'transformOrigin' to compensate the children positions back to 0, 0 by adding a transformOrigin to the group. That might work when reading out the first child offset (= position) inside the group and use that value negatively as a transformOrigin to the group. So then I could (hopefully) apply a transform to the group like as it was originated all elements around 0,0 to set it to absolute positions. But let's start with the first method! I don't like that second option. Don't have a clue if what I'm writing makes sense to anybody reading this, if I explained myself well, but anyway... thanks again for your help @OSUblake. Sorry for the silly newby question
  7. Hi everybody, For projects I import svg-files created with graphical software like Illustrator and now mostly Affinity Designer. I'd like to do 'absolute' positioning of objects inside svg space most of the time. Till now I put the graphical elements on their 0,0 positions inside the svg by the graphical software to be able to do absolute positioning with TweenLite.set(... {x, y}...) or use transforms to put them on desired locations. But that's not my ideal workflow, because I have to change the design which generates the svg output. I prefer to keep the design as is and position the elements after loading the svg by javascript with TweenLite to the right positions by absolute svg-locations instead, but so far I can't find a way to do this. I understand some svg elements have attributes like cx and cy to set positions absolute, but a lot if time I need to animate svg groups <g> and they don't have these kind of properties. Or paths, wich would take a lot more extra code to change the data just to move an element. So Does anybody here know if it is possible to set absolute svg positions with TweenLite/-Max? That would help me a lot!! Thanks!
  8. Thanks @OSUblake. I switched from UglifyJs 2 to 3 and then to Terser to make it work, but I happily switch back if that will do the trick. Any idea on which version is the version I should look for? (and perhaps a webpack plugin that suits that version if you happen to know by chance?). 'Cause it seems to be a real maze when walking through uglify-things (the uglify3 source inside uglify2 repo, that kind of things) I probably don't make it to my next deadline to tryout other uglify versions, but when I find a little more time (maybe in between) I'm eager to try it out and use it for a next project. A version number would be highly appreciated. Thanks again!
  9. Thanks @GreenSock Jack. Wow, an overwrite mode and I see now even an onOverwrite event.. never knew about these. Guess I will spend some time later to go through all options there to see if there are more ones I didn't know about. But somehow had the feeling this was already build in, because it's pretty hard to think of something that isn't there. Also nice way to kill tweens of variables going through plugins. Thanks a lot for the beautiful work with obviously a lot of passion and experience put in there!
  10. 1) I want to start a tween on an x-parameter but there is a possibility another TweenLite is still tweening the same value. Now I think pretty highligh about Greensock and it wouldn't surprise me if it's clever enough to stop the running tween when starting a new one. But I'm not sure. On the moment I'm having a killTweensOf() before starting the new one, but is that really nececary? Or does TweenLite indeed kill the running tween when starting the new one on the same value-parameter? BTW, 2) I was about to killTweensOf a value uses with the PixiPlugin (which is pretty convenient for large projects BTW!). But I'm not sure how to killTweensOf parameters when we're using plugins. I can't find it in the greensock help, but might be overlooking something there. Is this the right approach if we want to kill all tweens tweening the x-position via the PixiPlugin?: TweenLite.killTweensOf(this.bmp, { pixi: { x: true } }); Or should we leave pixi and just use the x-value instead (so Gsap 'underwater' knows somehow the x goes through the pixiPlugin)?: TweenLite.killTweensOf(this.bmp, { x: true }); Thanks in advance! And I am happy tweening all day long. This lib is just so well made, it's just so fun to use! Especially together with svg, pixi and threejs! :)
  11. Damn... 66 viewer, but nobody here works with webpack together with babel and gsap?? I'm surprised. But wow, this terser mangler is pretty strange (and I'm sure UglifyJs works exactly the same, 'cause it almost seems like an exact copy): It even mangles default DOM-objects and methods like body, getAttribute and all, making the result useless without putting all those keywords in a reserved array. I'm starting to believe no one in the world is using this mangle functionality. I just can't believe this...
  12. Thanks for your response @GreenSock. I appreciate it. Hope anybody else could help me with this!
  13. At the risk of being a little off gsap in this question I'm hoping anybody could help me with this. As I figured I'm probably not the only one having this situation with using gsap and webpack and wanting to mangle during minify. In Webpack I'm using babel to transpile gsap from 'gsap/all'. By imports it also going through the uglifgyjs-webpack-plugin (or uglifyjs-3-webpack-plugin or terser-webpack-plugin) perfectly fine with minifying (I tried all three webpack plugins and they have the same config-interface). I'm using this setup for months now without any problem and I am very satisfied with it, but now I want to mangle my source code and that's a different story. Enabling mangle doesn't throw problems and works, but when I set mangle.properties to true to mangle my properties things are starting to throw errors because the browser can't find things no more. The things it can't find are all inside the gsap lib and other libs like createjs I use. So what I try for days now in all kind of ways is to exclude the libs from the mangling. But so far without success. I tried putting things like 'TweenLite', 'TweenMax' and all in the reserved array (mangle.reserved) of the config object of the minifier (and also in the mangle.properties.reserved), but it doesn't seem to help or I am doing things wrong. I even tried skipping the minifier for the whole node_modules folder with a regEx property of the plugin, but I believe that's not working because uglifgyjs or terser webpack plugin only seem to minify at the very end of the buildflow, so after combining every javascript source into one file. And there seems to be no way to only minify/mangle webpack trunks before that (yet). I also tried using the regex-property inside mangle.properties (mangle.properties.regex) to only mangle properties that are important to mangle. But when I for example put a regex to mangle the property 'settings' it isn't that clever and just seems to replace all properties named 'settings', which could be totally different properties from different objects in my code. So that doesn't seem to be working as wanted or I am missing something perhaps. After days of working on this I'm kind of stuck on how to get this mangle to work. And I would be very surprised if it's not possible to leave libs out of the minifier/uglifier or having them still in but without 'can't find this and that' issues. This seems like a pretty basic workflow to me a lot of developers are probably using. I just think it's hard to believe there's nothing build in the module to get this to work, so I'm sure I'm missing something. How are other developers make mangling work on webpack without the can't find issues, like 'can't find Power4' of used libs? And I also can't find a reason why it can't find things in the mangled output, while the uglify plugin knows all code that is being used, because it's combined by webpack to one single file with everyting in there, all source code, all libs, so all references to objects and properties should be known by the mangler I'd say to mangle without problems. Perhaps webpack is making mangling more difficult, because the webpack output is pretty different, but still, this is a webpack-plugin I'm using, so it should know everything in there... Can't get my head around this. I'm stuck. So I passionately hope anybody here could give me a clue or could share their knowledge on how you guys keep gsap out of the mangle while using webpack 4! Thanks!!
  14. For what it's worth on this months old thread: when running webpack-dev-server uglifyjs will never fire. At least not in development mode. Minifying only happens on a production build. The problem you were having might be the same I had months ago too on Webpack with GSAP. In the end I just used Babel on the node_modules gsap folder too so it got transpiled to ES5 when loading modules in the es6 code from 'gsap/all'. Since then no more problems like this. So if you still have this problem it could help you too.
  15. Hi @vishal19696 , yes, its on the second post in this thread: import CSSPlugin.
  16. @Jonathan and @Dipscom Thanks for your responses. Yes, that's what I read too on the Adobes forum of what I included a link in my question. Strange thing though was that there is no passive animation running or whatever, but an interactive that is actively being used with touch. I luckily just found the real problem. On the page there are several iframes that gets lazy loaded when almost scrolled into view. The problem that made one of the animations slower wasn't in that interactive, but in the next one. And it's a strange iOS-only thing. It works (and was tested) fine on all other devices and browsers, including Macs. But failing miserably on iOS. The problem on that other animation was something nasty like: On a resize event I set threejs to change its renderer size to window.innerWidth/window.innerHeight (in this case the width and height of the iframe), which was than triggering an resize event (why?? nothing resizes. This event never happens on window, nor on Android,nor on windows phone, nor on Macs, nor on iOS when not running from inside an iframe)... which was causing threejs to change it's renderer size triggering another resize event... and so on and so fort. And on every renderer-resize threejs made the canvas just a little bit bigger... resulting in an endless loop of the canvas slowly growing and growing and growing and growing... nasty. So I now limit the parent to 100% width and height and set a boolean to false which was causing threejs to set absolute widths and heights in styles. Although strange that this growing happened in the first place, thankfully this did the trick. It's like on iOS window.innerWidth and innerHeight aren't window sizes, but document sizes. And for some strange reason it thinks the document height changed or something like that. silly. This was a real crazy one. And really only happening on iOS.... everything was working very smoothly on MacOS everywhere. crazy stuff. Glad I found out what the problem was. And that without even owning any iOS device myself... But yes! Everything is running smooth as butter now on iOS too!
  17. Hi there, thisone isn't about GSAP directly, but about animations using GSAP, canvas, svg and/or whatever that run from inside iframes on iOS. I just noticed that a lot of my animations are running very slow when running from inside iframes on iOS. So far I could unfortunately only test these in iOS through Safari, so this could be a Safari specific issue instead of iOS specific. I just found this still pretty new thread on the Adobe forum with more people having the exact same issue. So it's surely iOS and/or Safari specific. Even on my mobile phone on Android all my animations run very smooth, even with pixel ratios of 3. https://forums.adobe.com/thread/2435603 When the same animations/interactions, like animations using GSAP draggable together with SVG, DO run very smooth in iOS when not from inside iframes. On the moment these animations and interactives are just useless running from inside iframes on iOS, but I need them to play from inside iframes, so this is definitely an issue here now. I know this is not directly GSAP related, but because here are so many people together probably eperiencing the same issue, I hope somebody here knows of a some workaround for this so Safari iOS users can view the interactives/animations like supposed to. Anybody here facing this issue knows a way to get past this (probably before Apple fixes the problem)? That would be very much appreciated!
  18. Yes!! That was it. Thanks for the quick response @GreenSock Jack! So I guess that means Webpack is not using treeshaking during development, so you can only tell after a production build if everything survives treeshaking... that's kind of scary, but good to know now! Glad it works! Thanks again Jack!
  19. Moving an existing es6 animation project from Webpack 3 to Webpack 4 I'm facing a weird phenomenon according to the _gsTransform object when I move from 'gsap' to 'gsap/all' imports. Maybe it's the very high temperature here at the moment, but I can't really get my head around why this is... At the moment unfortunately I can't find the time to create a small project to show you guys, but if I can find the time later on I'll setup one. If I can't fix this with 'gsap/all' I'll stick with 'gsap' on this project for now and fix it later, but it would be great if maybe by chance anybody faced the same problem and could point me in a direction. The thing is that by running the webpack development server on the project everything works like it always did. Also when I move all greensock imports from 'gsap' to 'gsap/all'. But as soon as I let webpack create a production build and run the build from the dist on my local server, suddenly it won't run because the _gsTransform object I use to get a position of an svg-element is not there anymore, so it can't read x and y from it. At first I thought it could be the treeshaking thing which could be different between development and production. So I included all gsap modules I use in a constant, like the examples on the greensock website. So like: import { TweenLite, TimelineMax, Linear, Sine, Back } from 'gsap/all'; const uses = [TweenLite, TimelineMax, Linear, Sine, Back]; But to my surprise that didn't solve the issue: the _gsTransform object just isn't there on the DOM/SVG-element on the production build. Which is there and working fine when running a development build and running from there, or running from webpack-dev-server. I know webpack 4 does some things differently when mode is set to production, but I can't find a reason that something could cause to prevent the _gsTransform to be on the svg-element on production builds. I also switched off uglifyjs and all, so this cannot be some strange renaming thing. In the end I even made both development and production using the exact same stripped config, but still only the development build works and has the _gsTransform object. To me this doesn't make any sense so far and I'm out of ideas now. Anybody here perhaps knows if there is something extra I need to do, or maybe import from 'gsap/all' to make _gsTransform work and available on production builds? To be clear: using imports from 'gsap' everything works on production builds too, the problem is only there when importing from 'gsap/all'. It seems like some needed part of greensock is not make it after treeshaking and I needed to import something extra from the lib which I didn't needed to import before, when I was importing from 'gsap' (and the full package came with it, because there was no treeshaking). But even then I think it's strange that the development build doesn't have this problem with 'gsap/all'... crazy Again, if I can't find some solution today I will stick on this project on 'gsap', so it's not a grand big of a deal, but I'd rather switch. Thanks!
  20. Yes! Today I had some minutes to look at it again and with fresh eyes I saw in my code there were still some classes left were I forgot to change 'gsap' into 'gsap/all'. Crazy, I know. Silly me. Now everything is working as expected! Before the bundle was 547kB by importing from 'gsap', now it's 474kB by switching to 'gsap/all'! That is what I like to see! Nice! I like it. So to conclude: adding { modules: false } to the babel config was the only thing needed to make this thing work with treeshaking. In the meantime I took the time to switch from Webpack 3 to 4, which makes building even faster, and invested some time to really dig through the workings of webpack, resulting in an even better and smaller conditional config. I can say this was an educational experience! Thanks for your help @OSUblake and others via the other thread, Happy with the new gsap 2.0.1. It was fine to bump against trees without something falling out before, but my new setup gets the coconuts it needs from the trees now! Case closed!
  21. @OSUblake Wow, I didn't know const was supported by some older (ES5) browsers. Thanks for the info. Please keep in mind that IE9 and IE10 do support ES5, but don't support const. We can debate about if we still need to support those old browsers in 2018 (and I'd like to say no), but some of us still want to or need to support those for some projects if it doesn't take too much extra effort (and money). That's one of the major adventages of using greensock
  22. I changed my .babelrc to this now and with some little testing I see it's making treeshaking work if I just create a small project and import some functions from a file. So for this it's fixing treeshaking with using Babel. { "presets": [ ["env", { "modules": false }] ] } But for some strange reason in my project the bundle output filesize is still larger when I import from 'gsap/all' instead of from 'gsap'. Probably I have another mistake somewhere or something else I don't know about or am aware of. It's getting late now, so that's for another day
  23. @OSUblake Just see your response is targeting me, sorry for reacting this late. And with my just renewed knowledge I now what you mean now I wasn't aware that for treeshaking to work we need to set { modules: false } on the babel settings, just to only transpile all innercode to es5 and leave the module-structure/definitions the es6-way. Never knew this before. I'm now having this for presets in .babelrc, keeping the es6 modulestructure intact, and transpiling all code inside to es5, so Webpack can still play with shaking the trees, while babel transpiled the inner goodies: "presets": [ ["env", { "modules": false }], ], @einomi If you use webpack and want to keep es5 output like me, maybe you could stick to using babel in your setup to transpile. Then those es6 const's and stuff don't matter anymore and both IE and uglifyJs are happy. Here it runs fine now, except for a strange treeshaking thing I'm facing now causing filesize to become a lot bigger using from 'gsap/all' instead of from 'gsap'. But that's something else, although as it seems very much babel-related. see other thread here:
  24. mmm... it's starting to look like there is something not right on my babel-loader config. Just letting you know in the meantime I'm googling and just stumbled upon this thread: https://stackoverflow.com/questions/47663486/webpack-3-babel-and-tree-shaking-not-working explaining what might be the solution to the problem I'm facing: babel is transpiling everything to ES5, but Webpack only does treeshaking on ES6 modules, so it looks like I need to set { modules: false } on babel-loader in order to output ES6 modules with ES5 content, so Webpack still sees ES6-modules and can use that to shake the trees. If that's the case, so treeshaking isn't working now, probably a lot of my other projects will become a lot smaller too... that would be a nice plus side effect... But let's first find out if this is really the case... ** to be continued **
  25. @OSUblake Thanks for all your effort to explain people what you mean. I just checked your comparison project on github and I see you are using the exact same way I'm using for imports. Like expected, 'cause you're a great programmer Looking at your project it makes very clear where our communication went off though: I want to export ES5 to be used in Internet Explorer and other browsers not compatible with es6, and you don't transpile the files, so keep all constants in the output bundles. Just look for 'const' in your files in the dist-folder, they are still there. And that's exactly why people are complaining that IE or uglifyJs don't like this approach; uglifyJs (at least without configuring and especially if you're using the build in webpack-version) is not accepting es6, so hangs on the const's during builds if we don't transpile to es5 first. Constants are not ES5, but ES6, so they throw errors on browsers like IE not supporing ES6. That's why I use Babel now to transpile the greensock modules into ES5 with a webpack import. I could also switch to the UMD folder instead and skip transpiling, because the UMD-folder contains es5 versions, but I'd like to use treeshaking and keep my files as small as possible, so I'd rather use the es6-stuff and let babel transpile what I use. Now we come to the reason I started this thread in the first place and I will try to get my point across again. Hopefully this time I'll be able to explain myself better and get my point across: * In your project we can see that your imports from 'gsap/all' result in a much smaller bundle than importing from 'gsap'. Exactly as what I would expect and what is advised on the greensock website. So that's fine for modern/future browsers, but like said above: this is not es5, and I want es5. So.. en here comes my point: * in my project, where I (need to) use Babel to transpile the gs-modules to es5, suddenly the result is the other way around: importing from 'gsap/all' results in a 65k larger file than importing from 'gsap', eventhough I'm using the exact same approach for imports and so this should definitely be treeshaking in practise. To me that is totally the opposite as what I would expect. And that's why I started this thread, 'cause eventhough gsap/all is recommended for imports, why should I do that if the resulting webpack bundle is 65kB larger and does the exact same thing? I see in your project tree-shaking is working fine for a project without transpiling. So it's almost like treeshaking is not working at all with the gsap modules if we use babel-loader... I can't really understand why this is. Everything I write since a year now is in pure ES6 and I use babel-loader in webpack to transpile to ES5 in all my projects and it works as expected as far as I know. So something seems to be different in this case we are missing here... I'll further investigate...
×