| cedric | |
| Hermet | |
| jypark |
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.
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
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.
changing rounding stuff is ok to me but wondering why introduce additional condition (params->final.w/h > 0) there...
| src/lib/edje/edje_calc.c | ||
|---|---|---|
| 2433 | Is this (params->final.w > 0) condition necessary to come here? | |
| src/lib/edje/edje_calc.c | ||
|---|---|---|
| 2433 | It is because that negative value could come. | |
Something that would build more confidence in this not breaking the world somewhere... and silently.
Isn't that just the fault of people who change the internals of edje but don't add new unit tests?
History too. Edje has been in before there was a make check. Nobody bothered writing a serious tests suite for it that covered what was existing. Considering the amount of work it took me with just eina and eet...