Jump to content

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


  • Content Count

  • Joined

  • Last visited

Community Reputation

9 Newbie

About ynamite

  • Rank
    Advanced Member

Recent Profile Visitors

275 profile views
  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 he
  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 foll
  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 ren
  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 exceptio
  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
  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.