Jump to content
Search Community

strange behavior in Safari (only) - drawSVG

Donatello666 test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hi @Michelangelo666!

 

Thanks for the pen, it really helps.

 

Yes, there's definitely something funky going on but I think it's due to the number of things you're doing in you code, see my fork of your Pen bellow, it seem to work fine for me.

 

See how little is needed to achieve the effect you're after. GSAP has its own selector engine, and you can achieve a lot of cool effects with the .stagger()/cycle methods.

 

Note that I edited the SVG a tiny bit to simplify the animation code as well. ;)

 

Happy tweening!

 

See the Pen YrvNVX?editors=1010 by dipscom (@dipscom) on CodePen

 

  • Like 3
Link to comment
Share on other sites

Dear Dipscom,

 

Thank you a lot for answer. My original code is almost like yours (except 'staggerTo' and 'cycle'), i decided to deminify it and add a few things for this topic ;).

I love Greensock, and the past few years I did lot of cool stuff but what was new to me is the "cycle"-property, nerver used it before.

 

Changing the line-length was my first solution, but i want to be more flexible (and wanted to learn the usage of drawSVG), so i tried to change the length via drawSVG (-> 20% 80%).  I copied your code to my codepen (hope it`s ok?!) and changed

overlaySchliessenTL.from to 
overlaySchliessenTL.fromTo...{drawSVG: '20% 80%'}

and the strange thing occurs again (still Safari only). Do you have any idea why this happens?

 

BTW: I always used the jQuery way for my objects: var myObject = $('#myobject'). Does GSAP runs faster by using var myObject = '#myObject'?

Link to comment
Share on other sites

Hello, hello!

 

That is indeed a very strange behaviour. I can see what you are describing and probably @GreenSock is the individual that will be able to tell you why exactly this is happening and if there's anything he can do about it.

 

I can only have a guess based on inspecting the element and what I know of SVG behaviour. Basically, everything is doing what is supposed to do, in my eyes. The catch is how stroke-dashoffset and stroke-dasharray work together with the length of the line you're working with. I will assume you know the theory behind animating a stroke in SVG (if you don't, let me know and I'll dig something out from the interwebs).

 

All is working wonderfully until you rotate the line - as soon as you do that, it looks like the line is no longer the same length and Safari is not having a good time working out where the visible bits of the stroke should be. When inspecting the line, you will see that it is in the right place and the correct length but, the stroke-dashoffset is not quite where it should. Possibly a Safari bug... Possibly something @GreenSock can fix with his magic. Possibly, that's something you need to take in consideration when creating your SVGs... :(

 

I've amended my pen to just rotate one of the lines, so you can compare them.

 

PS: As for the selector engine - The difference will probably be negligible unless you are selecting thousands of elements - even then, it's probably not worth fretting over it. I never use jQuery myself - don't really need it - so I default to GSAP's selector. Less code to write.

  • Like 1
Link to comment
Share on other sites

There is some definite weirdness in Safari when rotating a line after a drawSVG animation like that. I tried a few other tests in Safari and it seems to behave correctly at rotations of 0, 90, 180, 270. Perfectly vertical or horizontal seem good, but during the rotation, the line slides off position. That's a strange one. @GreenSock may have some more info for us on this, but If you want a solution now, you can animate the x1/x2 attributes instead of using drawSVG. That seems fine in Safari to me.

 

See the Pen gGKKrq by PointC (@PointC) on CodePen

 

Hopefully that helps. Happy tweening.

:)

Link to comment
Share on other sites

Wow, that is one of the weirdest bugs I've seen in a long time. Definitely a Safari SVG rendering bug. If you look at the resulting HTML/CSS that GSAP sets, it's identical between Safari and other browsers. 

 

I poked around and found that if I changed your <line> elements to be <path> elements instead, and made sure to avoid using the regular "L" (line) command (I used Cubic bezier instead), it suddenly fixed the issue! Here's a fork: 

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

 

It's actually not that hard to convert lines into paths. You just slap an "M" at the front (move), then put the first x,y, then put a "C" and the final x,y coordinates 3 times. Like this: 

<!--OLD-->
<line x1="10" y1="25" x2="40" y2="25" />

<!--NEW-->
<path d="M10,25 C40,25,40,25,40,25" />

(there are other ways to do it, of course, but that's a simple one)

 

Does that help?

 

I don't think this "fix" should be automated in GSAP because it involves some pretty significant changes to the underlying DOM that could mess people up. Like in your case, you had a selector looking for "line" elements, so if we just automatically changed all of those to <path> elements, your code would break because the selector text wouldn't apply properly anymore. I wish there was a super simple fix we could apply. But again, this is definitely a Safari rendering issue, not a GSAP issue. 

  • Like 3
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...