->ext is getting freed during invalidate. If we unregister during
destruction (which is something that might happen) we should not
allocate the extension again.
Differential Revision: https://phab.enlightenment.org/D11524
This limit long chain of useless event forwarding when nobody is listening
at the end of the pipe.
Differential Revision: https://phab.enlightenment.org/D10813
we are going to add this description anyways, no need to count here
again. I think this is not really making anything really faster, its
more keeping things consistance.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10689
This should slightly improve speed in theory. In practice, I have not seen
a benchmark which would budge by 5%, so I am not sure it improve speed that
much.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10660
Today I started experiencing mysterious hanging of edje_cc
during build. "The French are at it again" I thought, and
after spending a while bisecting, I found the culprit.
It's 7f53d91583.
So, what is happening in here?
The idea here was fundamentally sound; compute a special
hash value for event descriptors, taking range between 0
and 63 (on 64-bit systems) and 0 and 31 (on 32-bit systems),
then use a mask sized 32-bit or 64-bit (depending on your
system) and check early if to bail out from callback_call,
saving some resources. So far so good.
The problem is in the way the mask is handled. We're applying
the hash as the shift value like, `x |= (1 << hash)`. On 32-bit
systems this is okay, but on 64-bit systems, C's dumb silent
coercion rules kick in, since the left side of the expression
is 1, a literal with type signed int; that means our shifting
range is limited to 31 and what we get is... undefined behavior.
This is obviously not what we want, so take a 1ULL value as a
base. The previous thing seemingly worked on x86_64 (nobody
reported any issues) and interestingly it worked for me too
for a while (on ppc64le), but undefined behavior can be
unpredictable, so...
This shouldn't need a commit message as long as this, but I'm
making it proportional to the amount of time I wasted on this.
EINA_FALSE is to be returned only if one of the callback did call
efl_event_callback_stop not if their was no callback called.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10620
Summary:
this cannot be evalulated in compile time, so this must be evalulated in
runtime, at the first call.
This should fix OSX build.
Co-authored-by: Cedric Bail <cedric.bail@free.fr>
Reviewers: zmike, cedric, raster
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10582
This patch introduce a small hash (64 or 32bits) that cache all existing
Efl_Event_Description callback handler registered on an object. It slightly
reduce the time needed to do an unecessary call and cost just a few bytes
per object.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10475
Summary:
this should be handled like the rest of eo internal events
ref T8321
Depends on D10353
Reviewers: bu5hm4n, cedric
Reviewed By: bu5hm4n, cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8321
Differential Revision: https://phab.enlightenment.org/D10354
a while back we have moved event submission from custom lists to eo
events. We also merged together the freeze and thaw functions, however,
this brought up one bug. smart_callbacks and the likes (those that used
custom lists before) are not effected by the legacy freeze and thaw
functions. This means, we should declare these legacy wrapper objects
unfreezable in order to obtain this behaviour.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Reviewed-by: SangHyeon Jade Lee <sh10233.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D10016
This should reduce the need for custom implementation of efl_object_provider_bind.
It also enable the ability to register provider from user code on any Efl_Object.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9292
Some user code may want to track an object ownership in regard to whether it is
kept by just one owner or shared between many owners.
This is specially true for code provided by bindings to other programming
languages, where different kinds of resource management may take place.
The event `ownership,unique` is triggered whenever the object refcount goes
from two to one, as a signal that it has just one owner from now on.
The event `ownership,shared` is triggered whenever the object refcount goes
from one to two, as a signal that it has multiple owners from now on.
It will not trigger when further increasing the refcount to any value beyond
two.
We also add benchmarks for sharing (i.e. increasing the refcount) and them
unsharing objects, in order to evaluate the performance impact of this patch.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8678
Until this commit eo did class functions as part of the vtable, which
enabled those functions to be overwritten in classes inheriting another
class. However in task T7675 we decided that this is not really good for
bindings, as most OOP languages do not support this sort of feature.
After this commit eolian realizes class function completly outside of
the vtable, the c-symbol that is the class funciton is now just directly
redirecting to a implementation, without the involvement of the vtable.
This also means a change to the syntax created by eo:
Calling before:
class_function(CLASS_A);
Calling after:
class_function();
Implementation before:
class_function(const Eo *obj, void *pd) { ... }
Implementation after:
class_function(void) { ... }
This fixes T7675.
Co-authored-by: lauromauro <lauromoura@expertisesolutions.com.br>
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D7901
This reduce the amount of time efl_event_callback_call(EFL_EVENT_NOREF) is triggered by a factor of 10.
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Differential Revision: https://phab.enlightenment.org/D7744
EFL_EVENT_SPECIAL_SKIP has been defined to 1 for a long time and there
wasn't a way to disable it at all. There is no reason to not use it at
all, so here we go. This was default, now it is without useless code.
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D7743
efl_noref is unused, but will still trigger the full eo call for nothing.
This was the most expensive NOOP. EFL_EVENT_NOREF does the same thing and
we can even filter generating that call as we know when someone is listening.
So removing the function.
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D7742
Note: Their isn't any ability to do something like a static array of
events at the moment. It might lead to large memory being used when it
wouldn't be necessary. If that was the case, we could fix it, but it
would require a lot of dynamic hash operation I think.
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D7482
If you are to trigger an event and just cancelled the one being processed, it would just
not propagate any event while it should. The code looks like more like it was forgotten line
or something.
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D7481
Summary:
In the case when you have multiple future in flight related to one object, you
couldn't use the previous version of efl_future_then. Now all function calls
take a void* pointer that allow multiple future to have their private data
request data accessible in all the callback.
This should not break released API as Eo.h is not released yet and so
was efl_future_Eina_FutureXXX_then.
Depends on D7332
Reviewers: felipealmeida, segfaultxavi, vitor.sousa, SanghyeonLee, bu5hm4n
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7472
Differential Revision: https://phab.enlightenment.org/D7379
Summary:
This commit add null check on _efl_object_invalidate
In EO_OBJ_POINTER, if obj_id is null, obj can also be null.
Test Plan: N/A
Reviewers: cedric, zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7068
Summary:
there is now invalidated & invalidating.
invalidated returns true when all children are invalidated, and the
object is / was requested to be invalidated.
invalidating return true when the object is called to be invalidated but
not all children are invalidated yet. However, the object is garanteed
to be invalidated in near future.
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric
Tags: #efl, #do_not_merge
Differential Revision: https://phab.enlightenment.org/D6722
recent changes added unlocks for these mutexes in some other places, so only
do the unlocks where necessary
fix T7020
Depends on D6356
Differential Revision: https://phab.enlightenment.org/D6357
Summary:
this brings down the first frame time from 2.0 sec. to something at 0.7
sec.
ref T6983
Reviewers: zmike
Reviewed By: zmike
Subscribers: YOhoho, cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T6983
Differential Revision: https://phab.enlightenment.org/D6244
Summary:
the object is invalidated AFTER the parent is lost, (thats what the doc
says). Returning invalidated as true when the parent is still present is
thus not correctly.
Depends on D6222
Reviewers: cedric, zmike, JackDanielZ
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6223
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Making wref disapear before the last event require additional work to use
them during the FREE event. As I think we should introduce a wref that
disapear after the invalidate state, it makes sense to move that to a later
stage. Especially because their is no specific event related to them
being set to NULL.
Allowing override of efl_del allow for messing with object life cycle which can create
problem for binding where an object was expected to be invalidated, but isn't really.
Marcel Hollerbach
Jérémy Zurcher
Wonki Kim
Cedric BAIL
Daniel Kolesa
Mike Blumenkrantz
Vitor Sousa
Cedric BAIL
junsu choi