forked from enlightenment/efl
try to avoid infinite recalc loop.
as reported, elicity triggers an infinite loop by calling edje_object_part_geometry_get(), which in turns calls _edje_recalc_do() which in turns calls the elicit code that requests edje_object_part_geometry_get() and since it's still marked as "dirty", it enters the loop... the real fix is just the move of ed->dirty = 0; before calling recalcs, but I also unmarked object as need_recalculate so we can even avoid requesting object to recalculate from evas. SVN revision: 38139
This commit is contained in:
parent
82c1c80632
commit
300c7b814c
|
@ -157,10 +157,12 @@ _edje_recalc_do(Edje *ed)
|
|||
int i;
|
||||
|
||||
ed->postponed = 0;
|
||||
evas_object_smart_need_recalculate_set(ed->obj, 0);
|
||||
if (!ed->dirty)
|
||||
{
|
||||
return;
|
||||
}
|
||||
ed->dirty = 0;
|
||||
for (i = 0; i < ed->table_parts_size; i++)
|
||||
{
|
||||
Edje_Real_Part *ep;
|
||||
|
@ -178,7 +180,6 @@ _edje_recalc_do(Edje *ed)
|
|||
_edje_part_recalc(ed, ep, (~ep->calculated) & FLAG_XY);
|
||||
}
|
||||
if (!ed->calc_only) ed->recalc = 0;
|
||||
ed->dirty = 0;
|
||||
ed->calc_only = 0;
|
||||
}
|
||||
|
||||
|
|
Loading…
Reference in New Issue