Jump to content


  • Posts

  • Joined

  • Last visited

About ynamite

Recent Profile Visitors

630 profile views

ynamite's Achievements

  1. @GreenSock Excellent, exactly what I was looking for. Thanks a lot!
  2. @Shaun Gorneau No real reason, just a gut feeling. Nothing against progressive enhancement, do that all the time, I've just never had to change the actual node type of an existing element before. Probably just me. Thanks for the help!
  3. Alright, easier done than said seems to be working fine. Still seems a little off to me but oh well, it works. Thanks!
  4. Hm, that sounds edgy. Can the tag of an existing element simply be changed? And if so, how? Edit: the whole element would need to be replaced, I think.
  5. Thanks @OSUblake After changing the <a> to a <div> it works fine and was much easier to implement than expected. The drawback is that the link will only work with JS enabled. Not sure if search engines will be able to pickup on these faux-links.
  6. Hi there draggable is working fine on my touch device, but not on my desktop using a mouse – latest Firefox Mac, haven't tested any other browsers. Anyone have any ideas as to why? In this specific case the element I'd like to be draggable is placed within an anchor-tag and I suspect that's where the problem lies. Adding `dragClickables: true` doesn't seem to make a difference. I could change the HTML, but I'd like to avoid that if possible, as this would require some amount of work and testing on project that is live. Thanks for the help!
  7. @ZachSaucier @mikel Check it out essential functionality's mostly done: https://dev.diener.coach Let me know what you think! Thanks again for all the help! PS. Will add a password later, send me a pm if you need it.
  8. This is what I have so far: https://codepen.io/ynamite/pen/wvzOgNd Performance is much better with separated paths (who would've thought). I wish I had a bit more control over what happens when though, feels a little arbitrary atm – been trying to use the individual durations to gain more control but getting inconsistent results, especially the further along the animation goes. Also I would've liked if initially all paths would be invisible (not yet drawn) and that the first path is drawn/animated. Only after this first path is drawn, does the rest follow by adhering to scrolltrigger. I tried doing it but it didn't work. Any ideas? Hope you know what I mean. @mikel actually it was useful once I knew what it was meant for haha. Thanks man! Thanks a lot!
  9. @mikel I don't get it and feel left out 😂 How does this help?
  10. Zach! First things first and just for the record: I love GSAP and I never implied nor meant to imply that GSAP had anything to do with it, not even close I'm simply trying to understand what's happening and to hopefully come up with a solution. That's all. I could be totally wrong, but what I'm trying to achieve doesn't seem overly complex. It seems to me that animating one single SVG path shouldn't be as sluggish as it is on my end, even on a 5K screen. But again, I could be way wrong (it may just be my machine/browser/config/whatevs), it has almost 10 million pixels more to render after all so you may be absolutely right. Just hard to swallow that an older, inferior tablet without a dedicated graphics card, using a legacy browser that's what, 8 years old now, beats a much newer machine with an up to date browser. Since all other browsers do just fine it makes me think it's neither the hardware nor the screen (resolution) that's the culprit. My money is on Firefox/my specific config. Thanks for testing. I'll check it out on my retina Macbook at home this evening, curious to see how that handles it. Cool, I'll try that next. Thanks a lot!
  11. @ZachSaucier Quick question, I've done additional testing on Windows and while it seems as though Firefox (latest version) is generally the slowest on Mac/Windows, it's exceptionally slow on my main workstation for some reason – a well maintained 5K Retina iMac (16 GB Ram, SSD, dedicated GFX card with 2 GB Memory) I believe. It does run a little sluggish on my old Surface 3 Pro too, but still way better than on my much more powerful iMac. Weird. What's funny is that even IE 11 manages adequate performance (once I got it to work). Every other browser – with the exception of FF – on the iMac/Surface draws the SVG quite smooth (as I would expect). I do feel performance degrades somewhat the further you scroll, but not too horrendously. So my question is, how do you perceive the performance in the above Pen on your end? You (and the others) never mentioned what your impression in regards to the performance/responsiveness is/was? In another test I tried adding another library (konva) into the mix – attempting to draw the SVG in Canvas while using ScrollTrigger. I feel like performance in Firefox is a bit better, but only slightly so (especially when scrolling by using the scrollbar, not the mouse wheel). The drawback is that the konva lib basically kills Safari as soon as scrolling happens. FYI: https://codepen.io/ynamite/pen/mdroPeK I'm gonna see if splitting the path makes any difference next, but would really appreciate some help on how to control that (start path B only once the end of path A is reached). Of course, any other tips on how to improve performance is greatly appreciated. I haven't quite given up yet. Thanks!
  12. It's already set to none in the pen above. Thanks though. Seems strange though ... I've seen fairly complex SVG animations that are way more complex than what I'm trying to achieve, and those run buttery smooth. Not to say it's a GSAP limitation, but it does seem strange that this fairly simple animation is so performance heavy. Thanks Mikel. Unfortunately I don't see anything that would help. Also your example doesn't run very well in FF either. Looks like Firefox just doesn't handle animated SVG paths all that well. Then again, the performance isn't great in any browser available to me, just way worse in FF, not sure why. It seems this whole approach simply won't work using DrawSVG and scrollTrigger. Again, not to imply that GSAP is in any shape or form to blame, but I still don't understand why performance is so bad in this case. Thanks all!
  13. Oh ... it seems it has to do with the visual size of the path. Running it in the small code pen window seems to alleviate the performance problems almost completely ... weird but interesting no? Please view the pen in it's full size and glory, as that's the size I need the path to be at As in, making it visually smaller isn't a solution.
  14. Hi all I'm busy coding the frontend for the aforementioned website but I have a few problems/questions. Here's a simple demo pen (please view in fullscreen): https://codepen.io/ynamite/pen/wvzOaOB (please view in fullscreen) performance: especially in Firefox (as compared to Safari) performance is quite bad. How come? I'm guessing the path is too long/complex? Or is there something else I'm missing? Can I do anything to make it run smoother? I haven't tried simplifying the path yet. Also performance in Safari degrades the further along the path is drawn. consistent pace / control path progress: it would be nice if the path was drawn at a consistent pace/speed. At the moment the animation isn't always visible. Is there any way to control this behaviour? Or is it simply due to how the path is setup – the anchor points/path segments? Would splitting the path up into several smaller ones help? If so, how would you make sure the next path segment starts only after the current segmet (in a scrolltrigger) ends? Thanks a bunch!