Jump to content

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

GreenSock last won the day on July 24 2019

GreenSock had the most liked content!


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by GreenSock

  1. I didn't have a lot of time to look at this, but there are some inherent challenges with scrolling on iOS. If you look at the scrollbar, you'll see that Draggable is indeed being responsive to your touch but iOS is counteracting it in certain cases (no doubt it's trying to be "helpful").  I'd probably avoid the whole scrollTop thing and just affect transforms instead, kinda like this: 

    See the Pen mdbPaqv?editors=0010 by GreenSock (@GreenSock) on CodePen


    Is that any better for you? 

  2. I know it's solved, but just to chime in - if your goal is to add a perspective(999px) to the transform while it's animating, you could try doing an onUpdate:

    tl.tl(element, 2, {scale:0.7, onUpdate:function() {
      		element.style.transform += " perspective(999px)";

    Just a thought. It could be made even easier with a helper function that'd automate some of that. 


    Anyway, happy tweening!

    • Like 3
    • Thanks 1
  3. That's very tricky indeed, as you're trying to use a native "click" listener instead of Draggable's built-in onClick functionality, but you're still making the same element draggable and in my opinion that's a bit risky because various browser handle things very differently. For example, some browsers require that you preventDefault() on the initial pointerdown/touchstart/mousedown event in order to avoid touch-scrolling while you drag...but if you preventDefault() at that point, then when you pointerup/touchend/mouseup, it won't recognize it as a "click" even if you don't preventDefault() that final event. Other browsers DO treat that as a click event regardless. I could go on and on about all the differences and bugs in browsers surrounding touch/drag/click behavior. 


    In your demo, it looks like sometimes the browser would dispatch the native "click" event first, but other times it lagged just a tiny bit behind the pointerup/touchend/mouseup event that Draggable taps into. I made a timing adjustment in this version of Draggable which seems to resolve this particular issue: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/Draggable-latest-beta.js but beware that it can't possibly solve other inherent issues related to trying to mix native event handlers with draggable events. 


    Unfortunately, dealing with all the various browser quirks is just a nightmare. Draggable does a really good job of normalizing things that you run through it, but if you're trying to straddle between letting it handle some things and using native events for other things...well, good luck with that ;) I can only really control what Draggable does with its own behavior. 


    Hopefully that tweaked version helps. I'd love to hear how it performs for you. 

    • Like 2
  4. 1 hour ago, greg_mich said:

    Update: The issue is that the polygon rotates around some other origin if that specific page is rendered but not currently the page being displayed. It isn't until the page is the focus or displayed page that it actually rotates around the origin desired.

    Any chance you could provide a reduced test case? I'm curious about this. Keep in mind that some browsers cannot report an SVG's bounding box unless it's visible in the DOM. 

    • Like 2
  5. 11 minutes ago, Julius Friedman said:

    What custom code is in the snapFunction pen?

    Oh, I didn't mean that your most recent demo had customizations made to GreenSock tools - I was just trying to be clear about what would make the ideal reduced test case. You've posted some other stuff that did include customizations, so I figured I'd mention it, that's all. 


    11 minutes ago, Julius Friedman said:

    FYI, this is the pen which has an issue

    That's what triggered my request for the most simplistic, basic reduced test case. Your codepen has a ton of other code that might (or might not) be causing issues. The goal was to isolate things as much as possible so we can get you an answer quickly and identify things accurately. It's just tough to parse through 400+ lines of code and try to understand what exactly your issue is, that's all. 

    • Like 2
  6. 26 minutes ago, Julius Friedman said:

    If the snapFunction runs more than one time there is something wrong no?

    No. I'm not sure why you'd think that. The purpose of the snap function is to run logic every time the pointer moves when dragging, so that it can apply any snapping necessary at that point. 


    28 minutes ago, Julius Friedman said:

    As you can see in the pen with the snap function I can get to index 3 by my setValue but can you ever drag the handle and get to all index's for both input and change?

    I'm not really sure what I'm looking for, but I see 3 different sliders. I assume you're talking about the bottom one maybe? I can drag it just fine all the way up and down. 


    29 minutes ago, Julius Friedman said:

    Let me know what I can do to better assist you with this issue.

    It would be amazing if you could provide a very reduced test case without all the custom code in there - just the most basic thing you can possibly provide that demonstrates the issue. Hopefully less than 20 lines of code total would be ideal. Thanks so much!

  7. I haven't had time to read through your entire post or all the code in your demo, but I wanted to mention a few things and then you can let me know if you still need some help/input: 

    1. In terms of snapIndex, wouldn't it be as simple as feeding the value into indexOf() to find what you need? 
    2. There are actually a deltaX and deltaY values attached to the Draggable instance - would that help you determine the direction that you're after? 
    3. Your getSnap() function seems to assume the type will always be either "x" or "y" (never "x,y" or anything else) which may be totally fine in your use case. I didn't follow what CS.context was (I did a search in the codepen and didn't find anything), nor do I understand what the "mean" was for. Are you trying to make it snap to increments of mean (starting at 0)? If so, that math looks right to me. 

    I like that the snap function is more efficient but if it's going to be called more times than there are snaps in the sequence then it doesn't make sense for me or I imagine many others...

    I was confused by this comment - wouldn't you expect it to run on every move event so that your custom snapping logic can be implemented in whatever way you want? Like...we can't necessarily assume that if it's outside bounds, that your snapping logic won't apply some other rule. Of course that seems like it'd be pretty uncommon, but when we let users define a snap function, we've gotta keep things open, you know? And I doubt that there's gonna be some noticeable performance hit from running that logic between snaps or outside bounds. Perhaps I misunderstood what you meant though. 

  8. I think I identified the edge case with edgeResistance intermittently causing problems (only when dragging outside the bounds of course) - it's just a rounding thing related to browsers only having a certain amount of precision when reporting the pointer's position. I posted the revised (uncompressed) Draggable here: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/Draggable-latest-beta.js




    I'm not sure that's at all related to what you were originally describing, @marya. Please let me know if there's anything else behaving oddly.

    • Like 4
  9. Sorry about the confusion there - I've never seen that happen before but your demo helped me find a very rare edge case in the conversion algorithm where the arc command "a" could run into a Math.acos(-1) which JS returns as NaN (weird!), so I implemented a workaround and uploaded a revised MorphSVGPlugin. Seems to work great now! (you may need to clear your cache)


    Like others have suggested, tweaking  your path would also solve the issue. But I want MorphSVGPlugin to be as bulletproof as possible :) 


    Thanks for being "Business Green"! 

    • Like 4
  10. I'm a bit confused about the "why" behind all this - if your goal is to synchronize your audio with a particular timeline, wouldn't it be much easier to just use an onUpdate on that timeline and check the time(), compared to your audio's time and if it drifts beyond a certain threshold, make your adjustment to the audio? 

    • Like 3
  11. Hm, I'd definitely be curious to see a reduced test case showing the GSDevTools behavior you described, but I think part of the problem may be the way you're handling things. By default, GSDevTools "listens" for any animations that are created in the FIRST 2 SECONDS of the page load (you can configure that). It's just a much more complex thing to have a GSDevTools instance constantly listening for anything that gets created, and adjusting everything on-the-fly. So unless you must have global functionality (that's actually kinda rare), I'd strongly recommend linking a GSDevTools instance directly to a specific animation, like:


    var tl = new TimelineLite();
    tl.to(...); //or whatever
    //now set the GSDevTools instance's "animation" to be your timeline or tween:
      animation: tl, // <- THIS IS THE KEY
      globalSync: false //and turn off the global synchronization

    Does that help at all? 

    • Like 1
  12. 7 hours ago, Julius Friedman said:

    It also doesn't seem like it's that complicated of a function to write on the basis on my point. You would just get the tweens for that element and look in the vars for the property being effected.

    It's probably more complicated than you'd expect. It seems your statement was based on the assumption that start/end values are always stored cleanly in the vars object, but that isn't the case. For example, a bezier tween may contain an array of values with nested x/y pairs (or any property). And there are many other examples like that. 


    Frankly, in all my years of doing this I can't remember anyone requesting this kind of functionality, nor have I needed it myself. Sure, there are times I may want to kill certain properties of a certain object from tweening, and that can already be accomplished with killTweensOf(). 


    I totally appreciate your thoughtful suggestions and they're not without merit. However, when developing a product like GSAP, it's always a difficult balancing act between packing in as much functionality as I can while keeping the file size down and the performance way up...oh, and trying to prevent the API surface area from expanding like crazy to the point where it's just confusing/overwhelming for end users. 


    I can't tell you how many times I've thought "well, in theory this feature might be cool..." or "oh, in this very specific use case, this feature would be nice to have..." and if I just keep cramming things in there, GSAP would end up becoming a monster. 


    It's certainly possible to add code to the core to allow you to getTweensOf(target, property), but I'm struggling to convince myself that more than 0.01% of users would ever actually tap into that and I'm not sure it's worth the added complexity, kb, etc. Others are certainly welcome to chime in - if we get a lot of requests for that type of thing, I'd definitely reconsider it. But again, in all my years of doing this (and over 8,000,000 sites using GSAP including most award-winnings sites), I can't remember anyone else asking for that type of functionality. (That doesn't mean it's without merit).


    Again, I sure appreciate the thought you've put into these posts and your desire to help us make GSAP even better. I'm working hard on GSAP 3.0 and I think you're gonna really like it. :) 

    • Like 3
  13. Ha, you're the king of super long, complicated posts today :)


    Are you just making suggestions for potential feature additions to Draggable? Or was there a problem/bug you wanted to report? 


    I'm not 100% sure I follow all that you wrote, but I'll mention a few things (none of which may be helpful): 

    • If you need both x and y involved in a snap, that's supported and here's a demo: 

      See the Pen wgapaY by GreenSock (@GreenSock) on CodePen

    • If you want to sense the direction of the drag, there's getDirection(): https://greensock.com/docs/Utilities/Draggable/getDirection()
    • We didn't implement *= or /= or %= because they're just not that useful and implementing them would force ALL users to pay the performance and kb hit for something that probably 0.00001% of the users may actually tap into. It just didn't seem like a good tradeoff. 
    • Your demo showing that scale:+=0.5 affected scaleX and scaleY seemed to work exactly as I'd expect. Am I missing something? Why would you not thing it'd affect scaleX and scaleY (scale, after all, is just a shortcut to affect scaleX and scaleY). 

    If you still need some help with something, yes, it'd be REALLY good if you provided as reduced a test case as possible and please keep the threads focused on one question at a time if you don't mind. It's totally fine if you open a few different threads - it's just too convoluted and confusing for people to follow when a whole bunch of things are mashed into one really long post :)


    Have a good night!

    • Like 4
  14. That basically means that "document" doesn't exist in that environment which is rather awkward because GSAP needs to tap into that in order to do various tasks. Think of it this way: it's like it's trying to run GSAP in a browserless environment (at least initially). It's the "server-side rendering" in Nuxt I guess. 


    Did you read that link that @Dipscom linked to above? https://nuxtjs.org/faq/window-document-undefined/


    Or if that doesn't work, can you just link to the files (perhaps on a CDN like cloudflare) instead of trying to run it all through an NPM-based build system that doesn't expose the document properly? 

    • Like 1
  15. 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: 

    See the Pen mNzPLY?editors=1010 by GreenSock (@GreenSock) on CodePen


    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!

    • Like 1
  16. 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. 

    • Like 1
  17. Yikes! Would you possibly have a reduced test case that doesn't have almost 1,000 lines of SVG? Maybe a simple Rectangle? :) Sorry, I've just got a VERY full plate right now and don't have much bandwidth to try to pull apart all the variables, sift through mountains of SVG data, etc.

  18. 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. 
    • Like 3
  19. 1 hour ago, Julius Friedman said:

    The only other feedback it seems I would like to provide is that when using the `MorphSVGPlugin.convertToPath` function, it would be helpful if one would take into account transforms on the source and target path, possibly with a custom function if someone desire or even more options but the main importance seems to be coordinate origin related `transform` attribute on the object being converted.


    Hm, would you mind providing a reduced test case in codepen that demonstrates a scenario where this would be useful? The tricky thing here is that transforms could be applied on the element and/or any of its ancestor elements, and they all stack up, so it wouldn't be as simple as "factor in the transforms". It would need a way of knowing how far up the chain you're asking it to go, you know? 


    Again, I think it'd help me a lot to se a very simple reduced test case that shows a practical example if you don't mind. Same goes for the fill issue. The convertToPath() function is intended to just convert the coordinates and attributes over which, in most cases at least, would ensure styling also gets applied accordingly but I'm sure there are some edge cases (like CSS with selectors like "circle {...}"), but hopefully that's a pretty easy CSS fix. Once I see a demo in codepen, perhaps that'll provide additional understanding for me.