The edje_part_recalc calculates next postion(p3).
Please refer to following line.
p3->final.y = INTP(p1->final.y, p2->final.y, pos);
If the condition is as blow, then p3->final.y becomes -50 only if pos is 1.0.
Because INP uses TO_INT not TO_INT_ROUND.
p1->final.y == -32 p2->final.y == -50
So we had nonsmooth ending of transition.
Sample application to check this issue. Please look carefully when the rect moves from bottom to top.
| No Linters Available |
| No Unit Test Coverage |
| Buildable 9457 | |
| Build 7966: arc lint + arc unit |
using round there looks fine but the modification of round function doesn't look right to me.
That is only valid for decrease case in negative values. increment in negative will be incorrect.
IMO, just leave round up as it does would be fine...
I just found that rounding rules has already defined on IEEE standard.
I think the round implementation as before this patch looks wrong as the standard rule.
(please have a glance at https://en.wikipedia.org/wiki/IEEE_754#Rounding_rules)
I mean, the way that cinoo wrote is right, isn't it?
Fix one more incorrect calculation.
The _edje_part_pixel_adjust could change final.w(h) value to -1.
This value is using in the _edje_part_recalc_single_rel, and has caused
incorrect position.
If final value is calculated by TO_INT_ROUND, then make _edje_part_pixel_adjust
use TO_INT_ROUND for eval value as well.