collections.group.use_custom_seat_names should be set to '1'
to use seat names on signals as provided by Evas.
By default just follow Edje naming approach
("seat1", "seat2", ...)
Seat goes as an optional parameter for FOCUS_SET (if not
provided, act over default seat), and emit signals
with seat suffix:
* focus,in,$SEAT
* focus,out,$SEAT
* focus,part,in,$SEAT
* focus,part,out,$SEAT
so edje was allocating 32 pointers per collection. this is per
collection inside an edje file even if we just use one collection from
that edje file. it consumes 32 pointers. on 64bit thats 256 bytes...
just for pointers to mempools so we can "optimize" freeing and
allocation of parts. this was simply rediculous. i moved it to a
sub-struct allocated on demand (so now only for collections we
actually use) and this nuked 400k of "base memory usage youcant get
rid of).
note that our current default theme has something like 1100 or so
images, 1500 or so collections in it. as theme gorws, memory footprint
goes up if we dont allocation only on demand (when needed/used) and we
aren't careful about the size of our data structs and their content.
@optimize
Previously, it was limited to the part block. It was a mistake
and should have been put in the description instead, as this
allows it to change during state transition (like visible, or
proxy_src_visible).
@feature
so ... Edje_Calc_Params was huge ... like about 200 bytes. every part
in every live edje object got one of these in addtion to real part
struct info etc. ... so really every part was probably consuming
300-500 bytes or so... crazy. so i made a lot of the data now optional
so only the minimum required is allocated now which cuts down about 110
or even 120 bytes per part, depending. 100 bytes was needed for 3d
node parts even though almsot no parts are 3d node parts... the image
and text data was 30-40 bytes so we consumed 100 even if we only used
30-40... so this cuts that done and puts in polace calc param cleanup
funcs everywhere they are needed to clean up this extra allocated data.
i also reduced this even more by maping pointers to req_drag, map and
physics and clip_to fields in another extension struct cutting
down another 28/52 bytes on most parts (in return for an added
4/8 bytes - on 32/64bit accordingly).
in elementary_test this saves about ~300kb of ram for just having the
etst run and displaying (peak memory measuremment). so massif says
10.6M -> 10.3M.
@optimize
fill spread and angle have never been used - resevred intitially for
gradient objects, but never put into use, so remove to get rid of
junk/memory footprint etc.
@optimize
edje was keeping every edje object created in an eina list so it could
access them later. not really great when every list node contains at
least 4 pointers (data, next, prev and accounting, possibly magic
too). also ever time an edje object is deleted it has to remove from
this list which means... walking the list to where the obj is... not
great. replace with an inlist which is just 3 ptrs, no extra pressure
on list pool and removal os O(1) too.
@optimize
this saves about another 80Kb or so in dirty pages by only loading
ephysics when needed. This removed ephysics and bullet library dirty
pages from the process space. this is another patch to address T4227.
@fix
Summary:
When using EDC written by another person, developer usually
does not need to know all specified parts in EDC but editable
like swallow, text or textblock parts.
The required flag tells whether the part is intended to be used outside EDC.
Reviewers: jpeg, cedric, raster, Hermet
Reviewed By: jpeg, raster
Subscribers: raster, NikaWhite, kimcinoo, jpeg
Differential Revision: https://phab.enlightenment.org/D3579
this should cut some memory used by edje by using smaller types like
shorts instead of ints where we just dont need a full int range and
short will do, and re-ordering in memory data soit packs better when
accoutning for alignment
Summary:
When edje_password_show_last option is enabled, the edje_entry uses <password=off>
for showing last character. But, when password mode is disabled by the elm_entry,
<password=off> is remained in the text. It can cause some problems.
Because, there is no way to control password mode by API for the edje_entry.
The elm_entry can't remove <password=off> tag before getting text from the edje_entry.
So, the patch adds edje_object_part_text_hide_visible_password() function and
the elm_entry will use this when elm_layout_theme_apply() is called.
@fix
Test Plan:
1. Run "elementary_test".
2. Show "Entry Password" demo. (Newly added by this patch)
3. Password mode is enabled. Put some text.
4. Click "Show Password" check box to disable password mode.
5. Put more text.
6. Click "Hide Password" check box to enable password mode again.
7. See a character among the text is visible. (without this patch)
Reviewers: tasn, herdsman, cedric, jpeg, thiepha, raster
Reviewed By: raster
Subscribers: Blackmole, z-wony, woohyun
Differential Revision: https://phab.enlightenment.org/D3988
Summary:
This is the svg loader which will parse the svg file and store it in a intermediate structure.
It provides the helper function to get EET descriptor to save the structure into eet file.
NOTE: Not all svg attributes are handled yet. but most common attributes are handled .
Reviewers: Hermet, cedric
Subscribers: Hermet, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3868
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This touches Edje and also Elementary where part names are used.
This commit blew up in size since now all content part APIs
(get, set, unset) require to use Efl.Part instead.
This is a big refactoring commit, but no logic should
have been changed. Fingers crossed.
This should now fix the part API usage once and for all.
EFL should have no part name in any of its APIs beyond
the Efl.Part interface.
Part proxy objects (may be real objects) have a lifetime
of only one function call, in a fashion similar to eo_super.
@feature
This is similar to the previous patch for Box,
but for Table.
Those new EO API as well as the legacy ones still need to
be tested (no test case in make check...)
@feature
Summary:
enum Evas.Canvas3D.Shade_Mode are using for choose relevant shader source code.
So renaming have a sence.
Rename evas_canvas3d_shade_mode_set/get property to evas_canvas3d_shader_mode_set/get
Rename internal fields and functions
Reviewers: cedric, Hermet, raster
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3882
Summary:
In evas and elm box, function for inserting child object after
referenced one is available, but edje doesn't have it.
This adds edje_object_box_part_insert_after() API.
@feature
Reviewers: raster, jpeg, cedric
Reviewed By: jpeg
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3733
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Adding of new properties for light in edje-3d. Recalculation of main properties in Canvas3D parts to provide animation (only those which I used in widgets).
Checking of frame existing when setting material.
Reviewers: cedric, raster, Hermet
Subscribers: jpeg, artem.popov
Differential Revision: https://phab.enlightenment.org/D3694
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
The "color_tree" block contains a list of one or more "node" blocks.
A "node" block consists of its own color class name and the list of child
color classes. At runtime, parent color class will be referred instead,
if child color class is set to part but its color values are not defined.
Reviewers: raster, Jaehyun_Cho, jpeg, cedric
Reviewed By: cedric
Subscribers: cedric, kimcinoo
Differential Revision: https://phab.enlightenment.org/D3606
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This is necessary for backward compatibility still I am thinking of displaying a warning for this
use case and request people to update there work and drop that feature in the future (In a year
maybe from now). Elementary doesn't need this as it depends on Ecore_Evas.
Summary:
APIs iterating works through active text classes and size classes were added,
but Edje_Text_Class and Edje_Size_Class data type are still concealed.
This patch uncovers those data types so as to allow developers to use them.
Reviewers: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D3557
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>