Jump to content
Search Community

Leaderboard

Popular Content

Showing content with the highest reputation on 02/25/2019 in all areas

  1. Sorry, but I don't understand what you are asking. Thanks for the demo, but I don't understand what to do with it. What is rechteck3a? Am I supposed to look in the SVG code and try to decipher the rgb value? fill="rgba(250,250,50,0.70) Perhaps you can try to explain 1 simple interaction, the result it gives and the desired result you would like. I'm guessing your issue has more to do with how SVGs handle transform origin and nested elements and not necessarily something related to gsap. I think that GSAP's smoothOrigin may help you. Please read section challenge: set transformOrigin without unsightly jumps at: https://greensock.com/svg-tips
    4 points
  2. Hi @Gianluca Giurlando and welcome to the GreeenSock Forum! Yes that is still valid. On the frontend of your website, check the browser dev tools Network panel and make sure your GSAP CDN script is being run/loaded before your custom GSAP script JS file. This way your custom code runs after GSAP is already loaded Also you might have to add a DOM ready event and window load event to make sure your code is running when the HTML markup (DOM) and window is fully loaded. // wait until DOM is ready document.addEventListener("DOMContentLoaded", function(event) { console.log("DOM loaded"); // wait until images, links, fonts, stylesheets, and js is loaded window.addEventListener("load", function(e) { // custom GSAP code goes here console.log("window loaded"); }, false); }); Check your dev tools console to make sure you see those output console logs. <?php // The proper way to enqueue GSAP script // wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer ); function theme_gsap_script() { wp_enqueue_script( 'gsap-js', 'http://cdnjs.cloudflare.com/ajax/libs/gsap/2.1.1/TweenMax.min.js', array(), false, true ); wp_enqueue_script( 'gsap-js2', get_template_directory_uri() . '/js/custom-gsap-scripts.js', array(), false, true ); } add_action( 'wp_enqueue_scripts', 'theme_gsap_script' ); ?> The link to the WordPress Codex for enqueuing JS files: http://codex.wordpress.org/Function_Reference/wp_enqueue_script For easy reference: Happy Tweening!
    4 points
  3. Yeah, I agree with Shaun, CustomWiggle would probably be the easiest approach:
    4 points
  4. Yes, I see what you mean @W2P Digital and that's tricky because the way SplitText determines if something is on a different line is if its y-position is different. In your case, of course, the bounding box of the bigger text is indeed different than the smaller text next to it. If we shifted to look at the x-position instead, that has its own challenges as well (like indentation would throw things off). See what I mean? If you've got any ideas, I'm all ears. This may be one scenario when you're better off manually wrapping things to specify your intent. I wish I had a great [automated] solution for ya.
    3 points
  5. Hi @kmytor, Using set() is quite different than to() or from() in that set() changes property values instantly (no tween). For example, In the above CodePen, the circle is tweened from x:0 to x:300 over 3 seconds and then immediately jumps to x:150 and then tweens from y:0 to y:100 for 2 seconds. The reason I used set() for the position property is that all position values are non-numerical values ('static', 'relative', 'absolute', 'fixed', 'sticky', 'initial', 'inheret'). Tweens will not happen for those values ... it will just jump to them. So, for the sake of keeping things clear, I like to use a set() where anything will jump to a value immediately. Note that when I say position can't be tweened, I mean the 'position' CSS property specifically. An element's position (i.e. placement) on the page can certainly be tweened with x, y, top, left, etc. Hope this helps!
    3 points
  6. Keep in mind that if you have your custom GSAP script inside your child theme directory, then you have to use the below code instead: Reason being is that get_template_directory_uri() returns the path to your parent theme get_stylesheet_directory_uri() returns the path to your child theme <?php // The proper way to enqueue GSAP script // wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer ); function theme_gsap_script() { wp_enqueue_script( 'gsap-js', 'http://cdnjs.cloudflare.com/ajax/libs/gsap/2.1.1/TweenMax.min.js', array(), false, true ); wp_enqueue_script( 'gsap-js-custom', get_stylesheet_directory_uri() . '/js/custom-gsap-scripts.js', array(), false, true ); } add_action( 'wp_enqueue_scripts', 'theme_gsap_script' ); ?> /js/ being the js folder in your child theme. Happy Tweening
    3 points
  7. <script src="TimelineLite.min"> (you left off .js) should be something like <script src="whereGSAPis/TimelineLite.min.js"> But you can't use TimelineLite without TweenLite AND you probably need CSSPlugin too. Since you are loading jQuery from a CDN I would suggest you do the same with TweenMax (which will include everything you need) <script src="https://cdnjs.cloudflare.com/ajax/libs/gsap/2.1.1/TweenMax.min.js"></script> or just load TweenMax locally like <script src="whereGSAPis/TweenMax.min.js"> For more info please see the Getting Started article: https://greensock.com/get-started-js
    3 points
  8. I'd probably just check the window width and set my values accordingly. Maybe something like this: You'd have to listen for a resize event and rebuild if necessary, but that should get you started. On a separate note, I see you're posting this project and questions in several threads. If it's about the same project and related questions, please keep everything in one thread. Thanks.
    2 points
  9. Yeah, sorry if that's confusing but all those callbacks are just special properties in config objects that show up in many, many places. The search applies to method, property, and class names (none of which are "onCompleteScope"). Did you need us to explain anything about onCompleteScope or anything else?
    2 points
  10. 1 point
  11. Hi @Exhumator, there reason for this is that there is only one set(). That function value is only being set() once and then repeated 5 times. You can use the Modifiers Plugin to accomplish this. https://greensock.com/modifiersPlugin Hope this helps!
    1 point
  12. Oh, I think the problem is actually that you have Dev Tools open! That puts a LOT more strain on the browser because it has to track and report a bunch of stuff, like all the CSS styles that get updated on every tick have to show up inside Dev Tools and get highlighted, etc. Try closing Dev Tools If you do a performance snap shot in Dev Tools (see attached), you'll see that the vast majority of the work is the rendering, not the execution of JavaScript. In other words, it has little to do with GSAP or CSS animations - it's browser rendering. You've got a lot of pixels that must update on every tick. I'm not sure there's a magic bullet here outside of rebuilding in <canvas> or something. Oh, and no, it can't be a server issue because that would only affect load time. All the animation stuff happens client-side. You might also want to open the "layers" area of Dev Tools and look at what you've got going on there - it's a LOT. And very big layers that need repainting/compositing. Even if you just refactored the scrolling background graphics to be in <canvas>, that might help a lot. I wish I had a great answer for you, but I think you'll notice things perform better when Dev Tools is closed
    1 point
  13. Well, it's not really that Illustrator is "messing up", per se - it's just that it tries to save the paths in as succinct a way as possible and the path commands end up being very different. In this case, you're trying to... //go from this: "M400,250A150,150,0,1,1,250,100,150,150,0,0,1,400,250Z" //to this: "M379,268c0,82.8-19.2,126-102,126S69,377.8,69,295S188.2,65,271,65S379,185.2,379,268z" Notice there are completely different path commands ("A", "c", and "S") and quantities of numbers. Part of the magic of MorphSVGPlugin is that it solves all of those problems for you - it interprets all the data and normalizes it into cubic beziers and also synthesizes extra points where necessary to ensure that things can be smoothly morphed and interpolated. When you try to do the tween with just AttrPlugin, it finds all the numbers in the strings, matches them in order (first number in the starting string with the first number in the ending string, etc.) and just tries interpolating. But of course that won't make any sense here. See the problem? If you're just trying to kick the tires a bit, keep in mind that MorphSVGPlugin is totally free to use on codepen. In fact, all the bonus tools are. See https://codepen.io/GreenSock/full/OPqpRJ/ Here's a fork of your codepen with MorphSVG doing its magic: Does that clear things up? Also, if you know the shapes have the same number of anchors, you could tap into MorphSVGPlugin's static methods to just convert the starting and ending values into cubic bezier data for consistency, and then plug that in (sounds like you did that with shapeshifter which I'm not familiar with): console.log("START:", getCubicPathData(blob.getAttribute("d"))); console.log("END:", getCubicPathData(morphData)); function getCubicPathData(data) { return MorphSVGPlugin.rawPathToString(MorphSVGPlugin.stringToRawPath(data)); } But again, that's not going to solve the issue of mis-matched quantities of anchors. I think you'll find that just letting MorphSVG do all that work for you is gonna save you a lot of headaches. We also introduced rotational morphing recently too, in case you didn't see: Happy tweening!
    1 point
  14. I can see some shaking on Chrome in Win7 64. This basically has to do with the fact that your page is using a lot of CPU cycles probably for a lot of calculations. There are two aspects that caught my attention. One, you have this PNG file http://yasserzakaria.com/sauditimeline/images/tlBackground.png that is transparent. Transparent PNG files, specially big ones, can be very expensive. Try without it and see how it goes. Two, you are moving this element: <div class="tl-eras-container" style="width: 22500px; transform: translate(27.3895%, 0%) matrix3d(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1);"> <div class="era" style="flex-basis: 2250px;"></div> <div class="era" style="flex-basis: 1750px;"></div> <div class="era" style="flex-basis: 3500px;"></div> <div class="era" style="flex-basis: 15000px;"></div> </div> That's 22500 px width, that's huge. This element is being constantly animated. Also you're animating another 22500px width element at the same time and finally you're animating a 2250px width element. All elements are being animated at the same time and that's causing a lot of calculations and repaints, and that's stressing a lot the CPU. In a smaller screen size performance is better. In terms of performance some layer updates are taking up to 35 milliseconds and the fps are dropping to 16 per second, that's definitely not good. My advice would be to try to move the card elements and not the entire wrappers/containers, especially that big, that could reduce the amount of calculations the CPU has to make. Also see if you can include either canvas or WebGL into the app, in order to improve performance. Finally, regardless of the performance issues, that is one good looking site, very appealing, intuitive, easy and fun to use, nice job!!! Happy Tweening!!
    1 point
  15. Welcome to the forums, @yasserzakaria1993. Thanks for providing the demo AND a video. You're quite the overachiever! We love that. I can't see any shaking whatsoever, but I know there was a Chrome bug (unrelated to GSAP) at least on the Mac version that caused slowdowns when 3D transforms were applied (which, of course, is the opposite of what should happen because 3D transforms should promote layerization to the GPU). I wonder if you'd see any improvement if you set CSSPlugin.defaultForce3D = false. Or maybe even try adding this to your CSS: will-change: transform. But be careful - https://greensock.com/will-change. You said that adding a slight rotation didn't help either, right? It looks like your original project (not the codepen) has a lot of graphics taking up the whole screen and beyond, so keep in mind that puts a lot of strain on the browser in terms of painting pixels on every tick (again, unrelated to GSAP). I realize you said that other browsers are acceptably fast, but I wonder if you just hit a particular edge case with Chrome with how it decides to rasterize/layerize things at certain sizes which isn't optimal in this case. Tough to know for sure without seeing the real project. Again, your demo looks super smooth to me in Chrome.
    1 point
  16. Hi and welcome to the GreenSock forums. Actually you nailed it. Since you're adding the element to the DOM on a specific event, that event is the perfect moment to either play/unpause an existing GSAP instance targeting that particular element, or to create a live animation (that is not paused) targeting the element. Now in terms of performance, creating the GSAP instances, that is running the code that makes each Tween/Timeline is not expensive at all, unless you create thousands of them. If you run into a performance issue it most likely will be the rendering part of the animations. Finally keep in mind that in javascript creating a variable, adds a reference to a specific reference to a place in the device's memory while creating the TweenLite instance on the fly, without storing it will save some memory, again a tiny amount of bits, not much. On the same subject GSAP has a very good and reliable way of sending instances to garbage collection so there is a guarantee that there will be no memory leaks in the GSAP side of the app. Hopefully this sheds some light into your scenario ad helps you. Happy Tweening!!!
    1 point
×
×
  • Create New...