Jump to content
GreenSock

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

Draw SVG - Circle changes direction

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

Small issue with my circle here, it works the first time on hover (in & out) and then changes direction.

 

Any ideas why it breaks after the first hover? 

 

It should look like this.

 

faq.gif?dl=0

 

Many thanks,

Smallio 

 

 

See the Pen VXZKPa by smallio (@smallio) on CodePen

Link to comment
Share on other sites

Hey @smallio :)

 

That's happening because you draw it from nothing (0,0) to (0,100) on mouseenter. Then on mouseleave you draw it from (0,100) to (100,100) so the beginning of the line is at the end for subsequent rollovers. (It draws from (100,100) to (0,100)) There would be a few ways to get the effect you're after. I think a simple approach would be to use a fromTo() tween instead of .to() tweens. Something like this maybe.

 

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

 

That will cause some harsh jumps with rapid hovering so you could also just create a timeline and play()/reverse() on hover as well. Hopefully that helps. Happy tweening.

:)


 

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

Thanks for the simple demo. Very helpful.

 

Good news: I know why it wasn't doing what you want

Bad news: I'm seeing a bit of a glitch that I can't explain at the moment.

 

So it wasn't playing the same way after you enter and leave once because the end of the "leave" animation was not the same as the start of the "enter" animation.

 

When you demo loads you set drawSVG:0%

When you first mouseenter you are tweening from drawSVG:0 to drawSVG:"100% 0%"

When you first mouseleave you tween to drawSVG:"100% 100%"

 

So now the next time you mouseenter you are not starting at drawSVG:0% as you were the first time you are starting at 100% 100% which is much different.

 

The solution is to make sure you mouseenter always starts at 0 and goes to 100 100.

 

you can do that with 

 

s.mouseover(function(){
  TweenMax.fromTo(c ,0.5, {drawSVG:'0%'}, {drawSVG:'0% 100%', stroke:'#fff', ease:Power1.easeInOut})
});

 

My demo is below and I'm curious to see what @PointC just posted before me:)

 

 

 

 

 

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

 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

BTW the "glitch" I was referring to is that if you mouseleave / mouseenter very fast the stroke will become super small very quickly and disappear which I don't think is right. 

 

@PointC gets around this by forcing the fromTo values in his mouseleave as well but that forces that tween to start with the stroke fully drawn even if you mouseleave when it was half-drawn. 

 

I'm going to have to look into my issue a bit more, as I'm not expecting that result

  • Thanks 1
Link to comment
Share on other sites

Thanks @PointC & @Carl respectively :)

 

I thought this might be the issue. Had a brain fart and somehow didn't think about using fromTo tweens, lol. Ah the joys of 2am developing :P

 

Thanks for clearing that up for me guys & also glad to have highlighted a possible issue with the small stroke, that was definitely adding to the confusion (along with it looking like the opacity was changing if you hovered quick enough). 

 

Hope it's an easy fix for ya Carl!  

Link to comment
Share on other sites

@Carl - o.k. I guess I'm not crazy. I saw that weird little glitch too. I thought maybe I was seeing things.

 

That's why I cheated a bit with forcing the fromTo() on mouseleave. Not an ideal solution, but I was typing fast. ;)

  • Like 1
  • Haha 1
Link to comment
Share on other sites

@Carl - The more I look at this, the less I think it's a glitch, but exactly the correct behavior. We're basically drawing from 0 on mouseenter and that gets interrupted (sometimes at really small percentages of completion) so then the plugin needs to draw the start and end point to 100,100. It looks correct to me in this slowed down version.

 

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

What do you think?

  • Like 1
Link to comment
Share on other sites

@PointC

 

is there anyway round this behaviour though? I like your idea of a timeline method but you can't reverse or it will just draw it the other way. It would be cool if there was a way to force it to to complete the full circle draw every time, then use onComplete to call a function from the mouse leave that does the same thing but with the other draw SVG params to make it pull back from the start vs just play & reverse. Going to give it a try later :D

Link to comment
Share on other sites

@smallio yes you can force it to complete the full circle and use an onComplete callback but then you have to consider what will happen if they mouseenter againg quickly while the mouseleave animation is playing. Are you going to wait for that to finish as well. I think whatever you want to do is all possible, you just have to see if its worth all the additional complexity. Also, if the animation doesn't appear to respond exactly to user interaction it could give the user the impression things aren't working properly.

 

 

 

@PointC Yeah, you're slow version definitely shows how I would expect things to work in all scenarions (cool).  But I still think something is amiss, perhaps even a rendering glitch.

 

I recorded my demo above at the current speed but edited the video to play at half speed. When I mouseleave even when the drawSVG value is something like "0% 75%" the stroke appears to shrink down to a hairline fragment and I'm not sure the end of the stroke segment should really go back to being that close to the beginning of the segment.  Give it a look here: https://greensock.d.pr/O8ucad

  • Like 2
Link to comment
Share on other sites

hmmmm... I see that in your demo now.

 

If you switch the listener to mouseenter instead of mouseover, it seems fine to me. Since mouseover fires over the child elements too, I think it's triggering twice.

  • Like 3
Link to comment
Share on other sites

Ah, yes, mouseenter seems to work fine. Doh. 

You are exactly right. 

 

Mystery solved

  • Like 3
Link to comment
Share on other sites

@smallio To me following implementation makes more sense if you don't want to get do a lot of Math. As for to complete circle from current position, it is going to take a lot of calculations to determine angle etc.

 

See the Pen ZxEYmP by Sahil89 (@Sahil89) on CodePen

 

Also, you should either use mouseenter and mouseleave or mouseover and mouseout. Though keep in mind they behave differently, usually mousenter/mouseleave does the job.

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

@smallio - I'd echo @Carl & @Sahil's thoughts about whether this is worth the complexity to make it happen. I really like @Sahil's demo, but with rapid hovering you can see that the line will sometimes be drawn in reverse. Whether a user would do rapid hovering, I don't know.

 

For these types of mouseover animations I almost always use a timeline that will play/reverse so rapid hovers aren't an issue. It may not be quite as cool as drawing on and then off, but it will save you some headaches. Just my two cents.

 

Happy tweening.

:)

 

  • Like 4
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.
×