Page MenuHomePhabricator

edje_calc: make INTP use TO_INT_ROUND
Needs ReviewPublic

Authored by kimcinoo on Thu, Jan 31, 2:30 AM.



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.

Test Plan

Sample application to check this issue. Please look carefully when the rect moves from bottom to top.

Diff Detail

rEFL core/efl
No Linters Available
No Unit Test Coverage
Build Status
Buildable 9457
Build 7966: arc lint + arc unit
kimcinoo created this revision.Thu, Jan 31, 2:30 AM
kimcinoo requested review of this revision.Thu, Jan 31, 2:30 AM
kimcinoo edited the summary of this revision. (Show Details)Thu, Jan 31, 2:31 AM
kimcinoo edited the test plan for this revision. (Show Details)

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...

akanad added a subscriber: akanad.Thu, Jan 31, 9:32 PM

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

I mean, the way that cinoo wrote is right, isn't it?

kimcinoo updated this revision to Diff 19147.Fri, Feb 1, 3:52 AM

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.

kimcinoo updated this revision to Diff 19327.Tue, Feb 12, 4:06 AM

If final value is calculated by TO_INT_ROUND, then make _edje_part_pixel_adjust
use TO_INT_ROUND for eval value as well.