in the event of fixed size -> non-fixed size (eg. previous commit optimization),
this calc would no longer occur, so we need to queue it. also if fixed.w or
fixed.h changes value for a group part, we must recalc the group to ensure correct
sizing occurs
when I said > 0 in the last commit message, I was thinking ahead to this commit
which I knew I would later have to make, but had not yet written because I had not
spent the requisite number of hours debugging the code to know that I needed to
have the check in both the code and the commit message
ref 3a451650d2
if the min/max of a part are identical and > 0, the part's min size is guaranteed
to be this size. there is no need to perform expensive recursive calcs here
_edje_real_part_image_set can change the image of part,
if the part use the image that is set by image set.
If the image is changed, the border should be changed.
@fix
It is in fact more coherent to follow the logic of visibility for map to.
So you don't require a specific state to finish your animation before turning
map off.
Summary:
This dpi is used to get the scale for each collection.
If each collection has a described dpi, it calculates a proper scale
based on the dpi and dpi which is described in the collection.
@feature
Test Plan:
If add dpi to collection of edc, the edje will save the value as the dpi of the collection.
For example, if the dpi of your device is 100, you just set dpi: 100 in the collection of edc.
If the edj is loaded in another device(dpi is 200), it will scaled 2 times.
It is possible that the described dpi of application and theme are different.
In that case, application and theme have a different scale.
It makes the edj that made in different environment works in one device.
Reviewers: seoz, zmike, JackDanielZ, Hermet, woohyun, cedric, raster
Reviewed By: raster
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1190
this massively improves edje performance when using groups, which previously would continue calculating their parts even when their parent object was hidden
CPU usage in my test case went from 20-30% to 1%.
@fix
In particular, ellipsis is -1 by default in Evas, but at this
point (first layout calc), the parameters used for recalc are
incomplete and ellipsis would then be 0 by default (calloc).
As a consequence, Edje will call ellipsis_set(0) enabling
ellipsis even on objects that force "ellipsis: -1".
Solution: set all the parameters before entering text/tb calc.
I believe the other changes are only color and image padding
and should not affect recalc_single.
Text objects declared in Edje will see their padding added twice,
as the Evas_Object_Text itself contains the padding already.
This WILL break some EDC files. It's a bug nonetheless.
Should this be backported?
Add to fuction prototype new param: Eina_Bool approximation.
If need exact matching state name and value set EINA_FALSE to
'approximate'. In other cases used EINA_TRUE.
Reviewers: cedric, raster, seoz
CC: cedric
Differential Revision: https://phab.enlightenment.org/D400
Signed-off-by: Cedric BAIL <cedric.bail@samsung.com>
Summary: Adding an option to use a cubic-bezier curve in edje transitions.
Reviewers: Sachiel, cedric, raster
Reviewed By: raster
CC: raster
Differential Revision: https://phab.enlightenment.org/D319
It is quite common that in an image sets each image has different border size.
This patch permit to define the border value on a per image basis in the set.
edje proxy parts seem to break (crash) when animating a state change from custom->default on an animator. adding a null check here avoids that and seems to work fine, but I am not an edje_calc expert
"edje: open Eina_File ourself instead of delegating it to edje."
"edje: don't never corrupt an opened edje object."
This reverts commits 8727e43c1f and 8f12f21cf0, which caused nonstop crashes.
This warning was removed but I left the _edje_real_part_state_get() in
there as this will not just get the part state, but also call
_edje_part_recalc() if needed.
Should we completely remove the block, or is _edje_part_recalc() required?
SVN revision: 82366
this is still in progress, mostly the multisense stuff is pending.
it seems that when we merge ecore_audio in edje the libremix and
similar are gone, at least from Edje, and will be in ecore_audio
itself (or pulseaudio).
Changes:
* __UNUSED__ to EINA_UNUSED
* binaries (epp, embryo_cc, edje_cc) now consider EFL_RUN_IN_TREE and
will assume the binaries are still not installed, running from
build tree location (needs more testing, maybe doesn't work with
srcdir != builddir, still doesn't solve cross compile builds)
SVN revision: 82139