| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
See: 82275b4c03a0. This workaround applies also for Symbian.
Reviewed-by: TrustMe
|
|
|
|
| |
Reviewed-by: TrustMe
|
|
|
|
|
|
|
|
|
|
| |
The failing (3) values are explicitly excepted here.
The source values for the comparison table should remain untruncated
doubles and the error bound checking function should be made dynamic.
Also the source values should come from a "trusted" source and not
from QEasingCurve itself.
Reviewed-by: Joerg
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
| |
The previous fix fails on msvc-2005, since QString::setNum()
does not handle rounding of numbers such as 0.015625 consistently.
|
|
|
|
|
|
|
|
| |
Easing curve autotests was converting the easing(qreal) to int before,
but this is a very rough comparison and was failing due to different
conversions to int, so now we do a qFuzzyCompare.
Reviewed-by: Thierry
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bug was in easeOutBounce_helper(), where the last else-block
adjusted t wrong. It should adjust t so that the peak is at t == 0,
but it adjusted it too little.
The old code did t -= (2.25f/2.75f), but it should have been 21/22.
The rest of the changes in that function is just simple mathematical
rewrites (use a more readable fraction), and removed the b argument,
since that was always 0.
Finally, fixing the original bug also revealed a bug in the first
line of easeOutBounce_helper(), where we always returned
1.0 for t == 1.0. That was wrong since it did not respect c.
|
| |
|
|
|