Summary:
Patch from a series of patches to rename EAPI symbols to specific
library DSOs.
= The Rationale =
This patch is from a series of patches to rename EAPI symbols to
specific library DSOs.
EAPI was designed to be able to pass
`__attribute__ ((visibility ("default")))` for symbols with
GCC, which would mean that even if -fvisibility=hidden was used
when compiling the library, the needed symbols would get exported.
MSVC __almost__ works like GCC (or mingw) in which you can
declare everything as export and it will just work (slower, but
it will work). But there's a caveat: global variables will not
work the same way for MSVC, but works for mingw and GCC.
For global variables (as opposed to functions), MSVC requires
correct DSO visibility for MSVC: instead of declaring a symbol as
export for everything, you need to declare it as import when
importing from another DSO and export when defining it locally.
With current EAPI definitions, we get the following example
working in mingw and MSVC (observe it doesn't define any global
variables as exported symbols).
Example 1:
dll1:
```
EAPI void foo(void);
EAPI void bar()
{
foo();
}
```
dll2:
```
EAPI void foo()
{
printf ("foo\n");
}
```
This works fine with API defined as __declspec(dllexport) in both
cases and for gcc defining as
`__atttribute__((visibility("default")))`.
However, the following:
Example 2:
dll1:
```
EAPI extern int foo;
EAPI void foobar(void);
EAPI void bar()
{
foo = 5;
foobar();
}
```
dll2:
```
EAPI int foo = 0;
EAPI void foobar()
{
printf ("foo %d\n", foo);
}
```
This will work on mingw but will not work for MSVC. And that's why
LIBAPI is the only solution that works for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Reviewers: jptiz, lucas, vtorri, woohyun
Reviewed By: jptiz, lucas, vtorri
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12203
if this is set to 0 the next iteration in the upper frame event would
decrement the 0 again leading to a overflow making the iteration and
callback array overflow.
Long story short: set ifx to 1 to prevent overflow, test added.
fixes T8787
Differential Revision: https://phab.enlightenment.org/D12101
we have these special counts which are > 0 when there is a callback
subscribed. THey are currently evalulated in _callback_call. However,
we can also skip the entire call from inside eo_base_class as we are
having the fields there as well.
This way we are skipping the obj pointer lookup and vtable lookup.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D12079
a little overfiew to how eos event emission is working:
- In eo there are 2 types of events restart events and normal events.
Normals are *always* emitted from callback_max to 0
Restarts are emitted from the previous emissions current idx to 0. The
previous emission will stop then
- To keep track of the previous event emissions for restarts there was
an eina inlist.
- To keep track of other things in eo, there was an additional eo event
stack frame (newly inserted events etc. etc.)
This commit now uses this event stack frame for implementing the details
about the restart events. This has the advatage that every
efl_object_data contains one byte less, and the up to date keeping of
the id's in the restart infrastructure is not needed anymore, making the
whole event emission code less instructions and faster.
How this now works:
- Every emission has a event emission frame, when the emission starts,
the frame is added, next points to the next older event emission. In
this event stack frame we are storing the current idx, the description
and a few other things that are not really relevant at this point.
- when a restart event is started, this event stack is searched from the
current frame up to the next one featuring the same event description.
The event frame stack is then remembered, if the event emission is
done, the current idx (normally 0 or something higher when callback
was stopped) is then copyied back to the earlier frame.
- Based on the nature of the event frame stacks, the idx is updated
every iteration. And for the restart events, we only need to know the
next, which removes the need of permanently updating the idx in the
current stack.
- The event frame stack is not allocated on the heap, hence more things
in there does not matter at all.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D12097
Revert "eo: redo vtable mro creation"
This reverts commit b05110609b.
Revert "eo: add a generic memory allocation tracking method"
This reverts commit 44071e3102.
Revert "eo: rework vtable allocation scheme"
This reverts commit 3bd16a46f1.
Revert "eo: do not allocate extension if deleting"
This reverts commit 64f7edc7fc.
This seems to breal vector rendering in lottie:
From: Hermet Park <hermetpark@gmail.com>
To: Enlightenment developer list <enlightenment-devel@lists.sourceforge.net>
Subject: Re: [E-devel] [EGIT] [core/efl] master 02/05: eo: rework
vtable allocation scheme
This patch occurs memory corruption, vector crashes :(
Here is a sample if you'd like to see it.
https://phab.enlightenment.org/F3858944
Summary:
->ext is getting freed during invalidate. If we unregister during
destruction (which is something that might happen) we should not
allocate the extension again.
Reviewers: woohyun, zmike, eagleeye
Subscribers: cedric, #reviewers, #committers
Tags: #efl
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.
Felipe Magno de Almeida
Marcel Hollerbach
Subhransu Mohanty
Carsten Haitzler
Jérémy Zurcher
Wonki Kim
Cedric BAIL
Daniel Kolesa
Mike Blumenkrantz
Vitor Sousa
Cedric BAIL
junsu choi