Jump to content
GreenSock

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

Leaderboard


Popular Content

Showing content with the highest reputation on 08/10/2019 in all areas

  1. 1 point
    Here you go https://codepen.io/juliusfriedman/pen/jgeBGJ I think that should be equivalent although the example is a bit contrived, its only really noticeable at the end when you morph back. I didn't think the morphSVG Hack was exactly a hack as it rectified the issue and reduced the number of errors in the console completely after use but non the less, I digress... For complete recognition of the issue I am attempting to describe I think we might need a SVG with 2 shapes e.g. a rect and a circle which are in different groups. If the morph is applied to a shape within the group then the group transform is not taken into account during the morph and it's position would not be with respect to the group, someone would have to manually position the morphed path either before or another the morphing starts. Hence why I was using scale to manifest the issue in these examples when in reality it might not be needed at all. If that is known and expected than it's fine, one would just have to determine their graphics don't have needless transforms and do the math to ensure their path coordinates have been transformed respective to the group they reside in. (which is why I call my example contrived) This was more of a hey, it would be cool if GSAP either could do this for us automatically (via option) or allow us to customize further with a function, it seems trivial to allow an option for transformDepth (to determine how far up) and a an optional function which would allow the resulting transform to be modified further. As I have already shown in my examples one can simply remove the group matrix or even take it a step further and apply those transforms to the paths or integrate those transforms into the point data. You guys already do a lot of work to provide options like xPercent and yPercent as well as support for transformOrigin with percentage based values so I just thought this would extend to that naturally and would otherwise be useful... As an example of how it could be useful given a Reflection scenario (like a mirror), lets say I have a an object and I want to show the reflection of the object but reversed and at a different scale and angle. Currently I would have to duplicate the object, transform it, position it and then create 2 morphs, one for the object and one for it's reflection, (Unless I did some use trickery, I suppose I could only morph the one and the reflection would then also morph however it would morph in exactly the same way) With this methodology I would only need to create the 1 morph and then apply it with the transformations of the 'reflection' to get both to morph in the same way but at angles respective to each if that makes sense. E.g. the main object is not rotated or scaled much but the reflection object is half opaque and rotated arbitrarily and at a different angle. There are other uses but they are even more complex and mostly benefit from re-using the morph and tweens rather than creating new ones. The color issue I also have worked around but thought it would also be a good enhancement since GSAP also already supports relative tweening with HSL, e.g. "hsl(+=0, +=0%, -=30%)", e.g. if you can say withOpacity(1, style) or better yet computeStyle(withClasses) to get a computed style of only the classes you want / will use. Perhaps when I get more time I can work on a plug-in which offers those options unless you get around to it first. Let me know if that makes sense and thank you again for your assistance! Please do let me know if I can do anything else! Regards
  2. 1 point
    Hm, that demo still seems to have almost 1000 lines of SVG and 200 lines of JS, with custom hacks of MorphSVGPlugin. I was really hoping for a reduced test case like: https://codepen.io/GreenSock/pen/mNzPLY?editors=1010 Can you fork that and do the minimum to recreate the issue you're referencing please? That'd be super helpful. Or if you've already resolved your issue and you don't think there's anything that needs resolving in MorphSVGPlugin, no need to press further. I just want to make sure we address any issues with GreenSock products. I'll definitely implement that fix regarding the extra "M0,0" at the end of your paths in the next release. Happy tweening!
  3. 1 point
    Do you have a reduced test case that proves this? I can't imagine why a browser would not use its cache in a scenario like this, but maybe you can show me the evidence you're looking at so we can better understand? Are you loading the GSAP file from a CDN? In all my years of doing this (and GSAP is used on over 8,000,000 sites), I don't think I've ever heard someone bring this up before. I wonder if there's a setting on your particular browser that's disabling the cache? What you're doing with hijacking the child iframe's jQuery (and GSAP) smells like a potential security violation, but that's not my area of expertise.
  4. 1 point
    If you're pointing to the same URL to load GSAP, the browser will only load it once anyway because it'll tap its cache for it. There's no point in trying to manipulate iframes like that (unless I'm misunderstanding your question).
  5. 1 point
    Sorry, I meant animate the divs, not the SVGs. Right now your parent divs (.priv-key-div and .pub-key-div) have no height because the child SVG is set to position:absolute. That's why your z-index isn't working. Make sense? Happy tweening.
  6. 1 point
    Yep, @Wipeo is correct - all CSS properties should always be camelCased. It's invalid JS to have a dash in there (JavaScript thinks you're trying to subtract from a variable).
  7. 1 point
    Yes, @PointC is right-on and I just wanted to add a couple of minor things: SVG doesn't have anything like z-index. It literally depends on the order of the elements in the DOM for stacking order, so you can get the effect you're after only by re-ordering things in the DOM dynamically. Totally possible, but @PointC's recommendation is probably easier and possibly more performant. Sine.easeIn, Sine.easeOut and Sine.easeInOut eases are probably perfect for this type of thing. Other easeIn/easeOut/easeInOut pairs could look nice too, but Sine waves are literally EXACTLY what drive this type of effect in the real world.
  8. 1 point
    Except that, try to change "background-color" to backgroundColor, as these props should be camel cased.
  9. 1 point
    I'd probably recommend separating the two into unique SVGs and put them in their own divs. Then you can take advantage of z-index. As for the easing, yes you should be able to create a smoother animation by adjusting the easeIn and out for your moves. You can also use a CustomEase. Happy tweening.
  10. 1 point
    @SENPAI & @xraymutation, This is trickier than one can expect because instead of using RTG to animate the transition between route components, the idea is to animate in a full page overlay, change the rendered component based on the new route and then animate the overlay out. Normally in RTG you pass the component that matches the target route which is animated. One solution I can think of is to play with the entering and exiting API's from RTG in order to animate just the overlay and produce the route change using a set instance in the addEndListener in order to have everything working with GSAP's timing. Of course this is easier said than done. Hopefully during the weekend I'll have some time to check this, but I can't make any promises since I'm extremely tight right now time-wise. An alternative is to create an animation in the overlay and use react router's API to make the route changes using GSAP callbacks. The trade-off in this approach is that you loose the capacity of animating the route changes using the browser's forward and back buttons, in those cases the routes change without any animation. Let me know which approach you prefer and perhaps we can work out something together. Happy Tweening!!!
  11. 1 point
    That's why I was suggesting checking out three.js, which uses a 3D renderer (WebGL). Moving and scaling objects in 3D space is pretty fast. Just think of how smoothly 3D video games are. You can still make 2D looking objects in 3D. The only problem for what you're doing is that you would need to convert most of your graphics into geometric objects/models, which might take a little work.
×