Note: A bug spotted in layout of box is the reason of this revert. From
my understanding, layout require some property on the object to be
correctly set. This is done during edje_recalc_single on the part. The
layout fonction of evas would be called just after the resize. If we
didn't do an edje_recalc_do, but an edje_recalc, the call to
edje_recalc_single will be delayed and the layout property will not be
set correctly.
SVN revision: 41698
WARNING: THIS CAN CAUSE RENDERING GLITCH AND OTHER WEIRD BEHAVIOUR WITH
YOUR EDJE FILE. PLEASE REPORT ANY ALIEN STUFF.
Note: This patch cache the result of _edje_part_recalc_single, until
any relative part are moved, the object is resized or some property
are changed (like during text set or color class set).
Note: Be carefull when you call edje_object_size_min_restricted_calc,
it's really an inderect heavy user of _edje_part_recalc_single and
I wasn't able to bring it down.
Note: This patch use more RAM, around 480 bytes per Edje state, so I
don't recommand using it on a Desktop with a lot of CPU power.
SVN revision: 41663
Note: It doesn't really impact edje memory foot print yet. But in
the plan to do a computation cache inside edje, this structure
will be used a lot (I am planning to do this feature at some point,
but no ETA yet, and be reassured it will be optionnal so we can
choose between CPU load or memory load).
Note: As I was looking for similar area of improvements,
Edje_Part_Description could really use an union to reduce it's size,
but as we load this structure directly from an Eet file, we need
union in Eet first. And this should be part of a comming Edje file
format break.
SVN revision: 41652
eina_list_search_sorted_near_list() was broken and barfed at my face
during development of eina_list_sorted_insert(), so I rewrote it
following more traditional approach, also adding special cases for
head/tail remembering that random access in lists is not as fast as
array. I also simplified that code.
eina_list_sorted_insert() should be fast, O(log2 n) insert, with
special cases to insert already sorted arrays forwards or backwards,
however I believe that it's better to simply append/prepend in those
cases (if known).
SVN revision: 41625
This should not impact anybody, at least in SVN I got no hits for this
function.
The new parameter contains the result of the last call to func(), so
we can know if the node is smaller, bigger or exactly the requested
value and don't need to call func() on node to know for sure.
SVN revision: 41623
eina_list_merge() now fixes the smallest list segment, not always the
right. Before if we joined a list 1 to 1000 segments we'd fix all the
1000 instead of the single at left.
Tests to make sure both code paths are being executed.
SVN revision: 41622
that still integrate cleanly with the EFL.
ecore_thread_run need two callbacks :
* func_heavy is called from another thread and should not use the
EFL except Eina, but carefully.
* func_end is called when func_heavy is done, but from inside ecore
main loop, so you can at this point call every EFL functions without
fear.
Note :
The system automatically detect how many CPU you have and will spread
the load on all of them.
You must not assume that the result will come in the same order you
requested it. Depend on each CPU load and how heavy the function on it
are.
SVN revision: 41555