Before screaming in horror (C++...) here's why we may need this:
Efl.Part.part API returns an object that is by definition valid for a
single function call only. Enforcing this in practice is actually quite
hard as all implementation functions must manually take care of the
life-cycle. This is a lot of code in many places and a lot of
opportunities to forget to properly handle that life-cycle. Also, this
means any invalid function call on a part will leak an object.
This API absolutely must remain either "internal" or "beta" and
definitely not become abused by applications. On top of that such an API
can cause great trouble for bindings like C++. As a consequence, only
specially crafted APIs like efl_part() should return an object marked as
auto_unref.
Alternatively this API could be defined in Eo.h or some other
Eo_Internal.h. I placed it in efl_object.eo because it's much more
convenient :) (read: I'm lazy)
****
Performance notes:
Tested with clang & gcc (with -O2), I had a look at the output of perf
top, in particular the asm view. I used eo_bench in a loop. My
conclusions are:
- EINA_LIKELY/UNLIKELY actually works. The jump statement varies
according to the expectation. I highly doubt all those ugly goto in
eo.c / Eo.h are even useful.
- The impact of auto_unref on a call_resolve is so small it doesn't even
appear in the trace. It is significant inside call_end, though
(obviously, that function is just a few lines long). That function
accounts for ~1% to ~4% of all CPU time. The impact of auto_unref in
call_end is ~4% of the function time. This means ~0.16% of all CPU
time (worst measured case). _efl_object_op_api_id_get simply doesn't
show up because of caching, so the extra check there is negligible.
PS: I also tested EINA_LIKELY/UNLIKELY by compiling with -O2 and looking
at the output with objdump. The flag is well respected, and the jump
instructions are what you would expect (no jump for LIKELY and jump for
UNLIKELY). Conclusion: The goto's in eo.c only make the code harder to
read...
Before this patch, the key would always be zero and the hash would solely
rely on the rbtree to be efficient. This improve the situation by using the pointer
as the key during hash computation.
Summary:
Some parameter's name are different in annotations and statements,
so it occurs doxygen warning.
To fix it, rename that parameters.
Test Plan: API Doxygen Revision
Reviewers: raster, cedric, jpeg, myoungwoon, Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5327
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Putting local variable "d" under preprocessor flag "EINA_SAFETY_CHECKS" to avoid below warning, if "EINA_SAFETY_CHECKS" is disabled.
1. local variable "d" is assigned but not used.
2. If warning 1 is resolved then variable "d" will be unused.
Reviewers: raster, cedric
Reviewed By: cedric
Subscribers: jpeg, rajeshps
Differential Revision: https://phab.enlightenment.org/D5321
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: assignment to local variable "ret" has no meaning as it is not used after assignment. So, removing assignment operation to avoid warning.
Reviewers: raster, cedric
Subscribers: jpeg, rajeshps
Differential Revision: https://phab.enlightenment.org/D5303
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
#finally
For now we focus the widgets of a item, the item content can be cycled
by tab / Ctrl + tab. up/down/right/left are for now handled by gengrid
and move the focused item (everything else feels super weird with
multiple contents in a item)
ref T6181
this can be used in a container that has his own item management api,
Each item management call results in a dirty call, once we are called to
prepare for logical movement we can simply flush the order. So we reduce
the spam of order calls, which also safes runtime.
Summary:
Some parameter's name are different in annotations and statements,
so it occurs doxygen warning.
To fix it, rename that parameters.
Test Plan: API Doxygen Revision
Reviewers: raster, cedric, jpeg, myoungwoon, Jaehyun_Cho
Reviewed By: cedric
Differential Revision: https://phab.enlightenment.org/D5313
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Summary:
Some parameters' name are different in annotations and statements,
so it occurs doxygen warning.
To fix it, change it appropriately.
Test Plan: API Doxygen Revision
Reviewers: raster, cedric, jpeg, myoungwoon, Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5316
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Summary:
if 'evas_object_smart_data_get' return null somehow,
logic that dereference the smart data pointer will cause problems.
This patch prevent a potential bug in advance.
Reviewers: jpeg, woohyun, cedric
Differential Revision: https://phab.enlightenment.org/D5290
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Summary: Unsigned integer should not be compared less than zero.
Test Plan: NA
Reviewers: cedric
Subscribers: shilpasingh, jpeg
Differential Revision: https://phab.enlightenment.org/D5274
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
thats just a little helper, where the logic to find and fetch the
provider is bound to the position in the widget tree, this means that
for example gengrid could change the way the logical parent is
evalulated. (For example to map the logical parent to a item)
eina_strbuf_append_strftime()
eina_strbuf_insert_strftime()
eina_strbuf_prepend_strftime() - macro
We need these functions for implementing generic format function
interface especially for calander.
Ref T6204
Efl.Animation and Efl.Canvas.Object need each other, and introduce a
cyclic dependency. Eolian doesn't complain... but C++ fails to compile,
as one header must be included before the other, and vice-versa.
Do we have other cyclic dependencies? I remember we lifted the
limitation in eolian itself, but can't remember exactly how it should be
handled...
Ping @q66 @felipealmeida
Simply pass in the strbuf and don't expect the callee to own it. This
makes things simpler and safer (it'll crash only if the callee frees
said strbuf, and shouldn't leak). efl_ebug_name is new in the upcoming
release, EFL 1.21.
Realised this after talking with Amitesh. Thanks.
See 999dbd9764
And c4769ff898
This is really several inseparable commits mashed together, as doing this
a piece at a time would introduce broken intermediate revisions.
Double buffer incoming "configure" state from the compositor so it's held
back during asynchronous render and processed at frame completion.
Hold off on certain requests if their API has been invoked during async
render.
This should fix a lot of races, cosmetic issues, issues where weston can
kill our clients for acking configure (or not) at bad times, etc.
This adds the concept of a "false commit" that just sends a surface
commit without changing any other state.
This is intended to be used by ecore_evas to request a frame callback
from the compositor
Seems my brain missed the efl release and started tagging new API
incorrectly in the doxy.
This is all beta API that should probably only be used by other EFL
internals anyway, but I suppose it's a good idea to try to be somewhat
correct.
Efl.Interpolator class is to interpolate a value.
Efl.Interpolator class has the following interpolation function classes
as its subclasses.
Efl.Interpolator.Linear
Efl.Interpolator.Accelerate
Efl.Interpolator.Decelerate
Efl.Interpolator.Sinusoidal
Efl.Interpolator.Divisor
Efl.Interpolator.Bounce
Efl.Interpolator.Spring
Efl.Interpolator.Cubic_Bezier
Efl.Animation.Group.Sequential is a class for animations started in
sequence.
Efl.Animation.Object.Group.Sequential is a class which provides
methods for an object of Efl.Animation.Group.Sequential.
The objects added into the sequential group animation object start
in sequence.