search

adobe-webplatform / Snap.svg

The JavaScript library for modern SVG graphics.
http://snapsvg.io
Apache License 2.0
13.95k stars 1.15k forks source link

bug with 270° #646

Open archilmede opened 3 years ago

archilmede commented 3 years ago

Using the patch from version 0.5.2, I still found a bug for a return to 0 °. Herewith the problem: `<!DOCTYPE html>

horloge `
ibrierley commented 3 years ago

I think you need to be a bit clearer what the bug is, and reduce the code to a minimal example.

archilmede commented 3 years ago

I am French and very bad at English ... In fact, the example given is a clock whose second hand returns to 12 o'clock (0 °) which instead of continuing in the normal direction, makes a turn in the opposite direction to restart in the normal direction. Indeed the angle does not progress any more arriving at 12h (the seconds return to 0). I think the fix works with a continual increase in angle but if it goes back to 0 and increases again it has a bug ... the needle rolls back to at 0 ° angle and starts again in the normal direction. See code ... I hope I was clear in my explanation ...

ibrierley commented 3 years ago

Can you put it on a jsfiddle ? Is it that it's animating to 0 rather than 360 or something ?

archilmede commented 3 years ago

Hello, https://www.developpez.net/forums/d2107546/javascript/general-javascript/snap-svg-mina-bounce/

-----Original Message----- From: Ian @.> To: adobe-webplatform/Snap.svg @.> Cc: archilmede @.>; Author @.> Sent: Mon, Apr 12, 2021 9:47 pm Subject: Re: [adobe-webplatform/Snap.svg] bug with 270° (#646)

Can you put it on a jsfiddle ? Is it that it's animating to 0 rather than 360 or something ?— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

ibrierley commented 3 years ago

Reading through that, it sounds like it's simply animating to 0, so this would be correct behaviour and not a bug (but I may be misunderstanding). You just want it to rotate to 360 and not 0 when the seconds are at 0.

archilmede commented 3 years ago

Let me explain : I simulate a clock, so after 60 seconds, the seconds go back to zero ... but the displacement of the seconds hand is done by 6 ° for each elapsed second ... I move this hand by rotation (transform ( 'r ....)) With version 0.5.1, I had the 270 ° bug .... so I took version 0.5.2, and there now, when the needle has made a full turn (360 °) and the seconds return to zero (return to 0 °) and well, instead of progressing in the normal direction (clockwise), the hand describes 360 ° in the opposite direction to reset to 0 ° and then start again in the normal sense. So there is a bug to correct ... Just take the code from the beginning of the discussion and put the snap.svg-min of version 0.5.2 to see the problem when the needle has made a full turn ...

In fact, it would be necessary to keep in memory the angle swept on a first rotation to add it in case of reinitialization on a second evolution of this angle which would avoid this kind of bug (this in the source code of the library ...) So, that's why I'm reporting a bug ...

ibrierley commented 3 years ago

There is no bug as such (that has been explained so far), an animation from a higher to a lower number will go in the opposite direction. You just need to handle crossover points. I.e this should fix the clock problem...

function anime() {
        now();
        calage_h_min();
        if( s == 0 ) { s=60 }
        if( s == 1 ) { seconde.transform( `r0,50,50` ) }
        seconde.animate({
            transform: `r${6*s},50,50`
        }, 1000, mina.bounce, anime);
    }
archilmede commented 3 years ago

So how to explain that version 0.5.1 manages the transition to 0 without problem ... the bug is at 270 ° and not at 0 ° .... Version 0.5.2 fixes problem at 270 ° but generates another one at 0 °. Yes, I can always modify my script to work around the bug but it is not logical and practical to have this type of behavior in the usual way ... It is rather surprising and uninteresting.

ibrierley commented 3 years ago

0.5.1 "works" (i.e it doesn't actually), but it works on 0 as it switches internally to represent -90 deg at 270, and animates from -90 to 0, which is "fine". All that's happened though, is it's broken at 270 instead of 0. It still has essentially the same problem, worse in fact.

If you look at older versions, eg 0.4.1 it has the same issue you are seeing in 0.5.2.

So the question is, what should happen when we animate anything from 359 to 0 (or 360 to 1) ? Should it go erm upwards, or downwards ? Of course it should go downwards. It would be completely incorrect for a tween between 359 and 0 to go to 359.1 or whatever.

It's down to you to make that happen. There's a few ways to skin a cat, but the most intuitive to me is to reset it, when it gets to 0, which is why I suggested that code.

archilmede commented 3 years ago

Ok, thank you for your answer and your explanations. I am not able to understand the problem in its entirety without having considered all the eventualities ... In the specific case mentioned, a simple addition of 360 ° to the reset value 0 fixes the problem ... After not having no test done on an evolution of the angle in the opposite direction after reset, I can not discuss ... That said, I find snap svg brilliant and again well done for this nice job! That's great !