TweenLite x position bug

[Daniel Segerstad]

I'm working on a website that needs to be very wide, more than 20.000px.

 

When I'm using TweenLite to animate x to <-20.000px it starts animating from 20.000

Ie, instead of animating from 0 to -20.000 it animates from 20.000 to -20.000

 

Any suggestions?

(If this should be a bug report, please guide me how to do that)

 

Thanks

Daniel

 

 

[GreenSock]

That definitely shouldn't be happening - I'd love to see an example. Can you please post a codepen or a jsfiddle or an HTML doc (zip it first) that clearly demonstrates the problem? 

 

And when you say "20.000px", do you mean "20,000px" (with a comma)? Otherwise, 20.000px would be the same as 20px, right? 

[Daniel Segerstad]

Thanks for a quick response. Yes, I mean 20,000px(huge)

I'll try to made a jsfiddle of it asap.

 

[GreenSock]

I know what's causing this, but give me a little time to devise a solution. Stand by...

[Daniel Segerstad]

Great!

 

I didn't manage to get the error when replicating in jsfiddle.

The site has a quite complex strucutre, so a simple extract didn't work out.

 

I reverted to beta version 1.65 and it works fine.

Using that in the meantime, deadline tomorrow

 

Oh and thanks a million for a brilliant library.

Have been a Green AS3 member for years.

[GreenSock]

Okay, here's the explanation...

You're absolutely right - when your "x" transform dropped below –21,474, it suddenly jumped to 20101. This had to do with a speed and precision optimization in the code that used a bitwise operation to round things to the closest 5-decimal places. What happens internally is I multiply the value by 100,000, add 0.5 (or -0.5 if negative), then use >> 0 to drop off the decimals, then divide by 100,000. This technique is literally 20 times faster than toFixed(5).

Apparently bitwise operations like >> and | force the number to a 32-bit integer which limits the value to 2,147,483,647 (positive or negative). When the bitwise operation was performed on the number that exceeded the max, it just returned 2,010,167,297 (forcing it to be positive too). Accommodating larger numbers is costly performance-wise, so I'm keeping the same technique for all matrix values (ones that affect scale and rotation) EXCEPT x/y/z because I can see people potentially using really large values for those (like you're doing here). I can't imagine somebody is going to scale their element beyond 21,474%. But now the maximum x, y, or z value should be just over 2 million so that should give you some room to play

I've attached a preview of 1.9.0 which has the fix in place. Please give it a shot and let me know how things work for you. Thanks for letting us know about the issue and for being patient with the response. Sorry about any confusion/frustration.

1.9.0.zip

[Daniel Segerstad]

Thanks for the explanation, hehehe 2 million should be enough

 

Thanks a million, it works like a charm!

Glad I could contribute, even though this might be the only time this was actually needed