a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
Summary:
We have back-ends that can generate their own tick sources, but
ecore_animator_add()/ecore_animator_timeline_add() gives no indication
which backend the animator is running on. This means that all animators
have to cause all currently in use backends to tick.
For example, if under wayland 4 application windows are open, all 4
windows will create ticks when any animator is present.
These new animator APIs that take an evas object allow us to figure out
out the backend and only cause the appropriate one to tick.
Depends on D7040
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: devilhorns, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7041
Summary:
These are the refcounted ticky guts of the signal add/del catchers, we'll
need to use these to start/stop from other call chains in the near
future.
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7039
Summary: I had fixed some typos and some wrong expressions in API reference doc
Test Plan: N/A
Reviewers: raster, zmike, Hermet, segfaultxavi
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6943
Summary:
this is a simple implementation of ignore_events functionality which
sets pass_events if it's an image or prevents the emission of events
in other cases
the result should be that no user events are received. this deliberately
does not block the triggering of resize callbacks as in the original ticket
since this guarantees broken functionality and is just not a good idea
fix T4700
Reviewers: devilhorns, Hermet
Reviewed By: Hermet
Subscribers: Hermet, cedric, #reviewers, #committers
Tags: #efl_display_system
Maniphest Tasks: T4700
Differential Revision: https://phab.enlightenment.org/D6876
Summary:
this should not take any action if the existing value of manual_render is
set to the passed value
Reviewers: devilhorns, kimcinoo, ManMower
Reviewed By: devilhorns, kimcinoo, ManMower
Subscribers: ManMower, cedric, #reviewers, #committers
Tags: #efl_display_system
Differential Revision: https://phab.enlightenment.org/D6786
Summary:
We need to pass the entire pointer, not just 32-bits of it.
Fixes a crash with enlightenment sandbox gadgets where
ecore_wl2_window_alpha_get() is called with an invalid pointer while
trying to display a pop-up.
Reviewers: zmike, devilhorns
Reviewed By: zmike, devilhorns
Subscribers: devilhorns, cedric, #reviewers, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6775
Summary:
If we call ecore_evas_manual_render() during an async render, it does
nothing.
This is harmful if we've added render post callbacks during that async
render and expect them to fire.
Force a sync and another render if we're in an async render.
ref T7156
Depends on D6714
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T7156
Differential Revision: https://phab.enlightenment.org/D6715
Summary:
Some ecore_evas such as ecore_evas_extn_plug doesn't have evas.
ecore_evas_extn_plug seems to be Ecore_Evas, but actually it is Evas_Object_Image.
ecore_evas_extn_plug makes new ecore evas, but it only exists to communicate with ecore_evas_extn_socket.
newly ecore evas only open and close file(ecore_evas_extn_socket). so it doesn't have evas.
```
EAPI Evas_Object *
ecore_evas_extn_plug_new_internal(Ecore_Evas *ee_target)
{
...
ee = calloc(1, sizeof(Ecore_Evas));
...
o = evas_object_image_filled_add(ee_target->evas);
...
return o;
}
```
Reviewers: zmike, Hermet, woohyun, raster, devilhorns
Reviewed By: zmike
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6504
Summary:
After a44697c37a, we can register same ecore_evas
to ecore_evases using ecore_evas_input_event_register.
(ecore_evas_input_event_register -> ecore_evas_done -> _ecore_evas_register)
This can make infinite loop in EINA_INLIST_FOREACH(ecore_evases, ee) because
next inlist of ecore_evases is ecore_evases after double call of
_ecore_evas_register.
This patch prevent it.
Test Plan:
Ecore_Evas *ee = ecore_evas_new(NULL, 0, 0, 800, 600, NULL);
ecore_evas_input_event_register(ee);
(part of document of ecore_fb_input_device_window_set)
Check that there is no infinite loop
Reviewers: zmike, devilhorns
Reviewed By: zmike
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6390
This reverts commit 2fb5cc3ad0.
Most of this change where wrong as they didn't affect the destruction
of the object. efl_add_ref allow for manual handling of the lifecycle
of the object and make sure it is still alive during destructor. efl_add
will not allow you to access an object after invalidate also efl.parent.get
will always return NULL once the object is invalidated.
Differential Revision: https://phab.enlightenment.org/D6062
Summary:
this mimics other engines, all of which have the same mechanics due
to display server interactions. it also avoids unnecessary recalcs before
pre-render if the canvas size was changing repeatedly
fix T6924
ref D6019
Reviewers: cedric, JackDanielZ
Reviewed By: JackDanielZ
Subscribers: #committers, JackDanielZ
Tags: #efl
Maniphest Tasks: T6924
Differential Revision: https://phab.enlightenment.org/D6145
so i found the work with wayland and having animator sources broke
that same source from ecore_x that was there from long ago, so i've
put in an exception if there are x based engines from restting to a
timer animator because ecore_x would have switched toa custom ticker
already, and this just resets it. also just set the source after
setting the tick callbacks and ensure tick cb's are null before going
to timer source as well. this cleans up this little but of animaatior
vsync modification to properly vsync in both x and wayland too now.
@fix
I want to use this in other engines, but no other engine initializes this
properly, so draw_ok would be EINA_FALSE everywhere. This way draw_block
is EINA_FALSE after calloc in all engines that don't know about it.
ref T6834
Summary: After migration this code in Tizen. The coverity said it needs to check return value(CID 39562).
Reviewers: raster, myoungwoon, woohyun, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5907
Reviewed-by: Cedric BAIL <cedric@osg.samsung.com>
so the MAIN loop is actually an efl.app object. which inherits from
efl.loop. the idea is that other loops in threads will not be efl.app
objects. thread on the creator side return an efl.thread object.
inside the thread, like the mainloop, there is now an efl.appthread
object that is for all non-main-loop threads.
every thread (main loop or child) when it spawns a thread is the
parent. there are i/o pipes from parnet to child and back. so parents
are generally expected to, if they want to talk to child thread, so
use the efl.io interfaces on efl.thread, and the main loop's elf.app
class allows you to talk to stdio back to the parent process like the
efl.appthread does the same using the efl.io interfaces to talk to its
parent app or appthread. it's symmetrical
no tests here - sure. i have been holding off on tests until things
settle. that's why i haven't done them yet. those will come back in a
subsequent commit
for really quick examples on using this see:
https://phab.enlightenment.org/F2983118https://phab.enlightenment.org/F2983142
they are just my test code for this.
Please see this design document:
https://phab.enlightenment.org/w/efl-loops-threads/
Summary:
This patch fixes a tentative crash owing to ptr dereference.
Unlike ecore_evas_object_cursor_set and ecore_evas_object_cursor_device_set,
ecore_evas_cursor_set uses Ecore_Evas *ee before calling internal function which
internally checks null ptr dereference of Ecore_Evas *ee.
Test Plan: Executes test suite
Reviewers: cedric, raster, stefan, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5753
Summary:
ecore_evas: remove debug
eina: unregister log level when done with
Fixes a constant memory leak.
eina: introduce EINA_HOT and EINA_COLD
These attributes respectivelly expand to __attribute__ ((hot)) and
__attribute__ ((cold)) when available. They allow to mark functions are
being hot/cold (frequently used or not) as well as to qualify labels
within a function (likely/unlikely branches).
eo: speed-up generated calls by removing call cache
The call cache needed to by thread-local, to avoid concurrency issues.
Problem with TLS is that is adds an extra overhead, which appears to be
greater than the optimization the cache provides.
Op is naturally atomic, because it is an unsigned integer. As such, it
cannot be tempered with while another thread is reading it. When
entering the generated function, the first operation done is reading
'op'. If we have concurrency, we will have access sequences returning
either EFL_NOOP or a VALID op, because 'op' is not set until the very
end of the function, when everything has been computed. As such, we now
use the 'op' atomic integer to instore a lock-free/wait-free mechanism,
which allows to drop the TLS nature of the cache, speeding up the access
to the cache, and therefore making functions execute faster.
We don't test anymore the generation count. This can be put as a
limitation. If means that if you call efl_object_shutdown() and
re-initialize it later with different data, opcodes will be invalid.
I am not sure there is any usecase for this to ever happen.
We could move all the caches in a dedicated section, that can be
overwritten after a call to efl_object_shutdown(), but I am not sure it
will be very portable.
Benchmark: mean over 3 executions of
ELM_TEST_AUTOBOUNCE=100 time elementary_test -to genlist
```
BEFORE AFTER
------------------------------------------------------------
time (ns) 11114111647.0 9147676220.0
frames 2872.3333333333335 2904.6666666666665
time per frame (ns) 3869364.6666666665 3149535.3333333335
user time (s) 11.096666666666666 9.22
cpu (%) 22.666666666666668 18.333333333333332
```
Ref T6580
Reviewers: raster, cedric
Subscribers: cedric, jpeg
Maniphest Tasks: T6580
Differential Revision: https://phab.enlightenment.org/D5738
because as of... i don't know when, evas relies on ecore with
ecore_pipe_add to create the async fd... and if you init evas then
ecore this doesnt work. obviously. well now it isn't working. probably
due to new efl loop work. but the efl loop code is correct.
ecore_pipe_add should never work until you init ecore... it just
happesn to have managed to be gotten away with for a while.
@fix
This fixes cycles of init/shutdown/init where ecore event types would
become invalid, since they are now stored in a dynamic array rather than
a statically stored array.
The risk here is that if a module of EFL tends to init/shutdown in a
"normal" scenario then the event type array will grow in a leaking
manner. This could be fixed by resetting those event ID's only when the
loop actually exits (EFL_EVENT_DEL on the main loop). I'm not using
EFL_EVENT_DEL in this patch as this would add too many event callbacks
to the main loop object, which may result in slightly slower event calls
to it, affecting the overall performance.
Summary: stat() wasn't working on Windows due to some msys2/mingw quirk.
Reviewers: felipealmeida, cedric, vtorri
Subscribers: jenkins, jpeg
Tags: #windows
Differential Revision: https://phab.enlightenment.org/D5520
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
In Enlightenment with internal window being WL window connected to the
X11 backend, you end up with the later requiring the former to tick, even
if the former do not have a proper animator source. To work around the
problem when there is one backend that is not providing support for
animator source, we do need to avoid switching on another window source
as they could be linked somehow and we can not know.
As we do not know when a window won't be able to tick, and we do
not know which window a legacy animator is attached to, we require
all windows to tick as often as they can and only generate one tick
per loop run.
This might need more adjustement especially with multi output.
It is not because a round of rendering happen for a child, that it result in
actually drawing anything in the parent. The parent will always be aware of
the rendering request of the sub surface and we should only track what the
parent think.
T6049
Tested-by: Derek Foreman <derekf@osg.samsung.com>
For this patch I decided to add a pseudo legacy wrapper as the function
is called in a very large number of places. Fixing all those calls to
use the size2d form is a lot of work and a greater risk of b0rking
something.
It's a complex struct but defined in EO as a simple struct. ABI-wise
it's equivalent to Eina_Rectangle. Some macros that use Eina_Rectangle
also work on Eina_Rect out of the box, most of the code dealing with
x,y,w,h will require no modifications either.
But Eina_Rect provides direct access to a size or position 2d component,
as well as the usual x,y,w,h. The field "rect" is provided as a
convenience for code dealing with both Eina_Rectangle and Eina_Rect. We
may or may not require it.
Note: Size2D could use unsigned values but I have spotted a few places
in the code that actually use -1 to indicate invalid size (as opposed to
0x0).
@feature
This backend has received no patch and maintenance from anyone who could
actually test it over the last few years. After talking with KaKaRoTo it
is best to remove it. If anyone want to take over its maintenance, you
are welcome to revert this patch.
Marcel Hollerbach
Derek Foreman
Myoungwoon Roy, Kim
Mike Blumenkrantz
Hosang Kim
YeongJong Lee
Cedric BAIL
Mike Blumenkrantz
Carsten Haitzler
Xavi Artigas
Derek Foreman
Chris Michael
Woochan Lee
Marcel Hollerbach
Vincent Torri
Jean Guyomarc'h
Jean-Philippe Andre
Lauro Moura
Taehyub Kim
Marcel Hollerbach