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.
the normal usage of these is something like
if (!strcmp(engine, my_engine))
win = window_get(ee);
which is a waste of effort since the window_get() functions all check
the engine interface internally
When a canvas is manually rendered the ticker is just a waste of cpu, and
worse - it can wake the drm back-end from dpms sleep, as the display needs
to be awake to generate vblanks.
We fire a DBG message when attempting to start an animator in this state
because it's frequently a bug that wastes battery life - (like E doing idle
cursor animations or clock updates while the display is off)
However, dpms off is not the only potential usage of manual render, so
another commit will follow shortly to fix the bug this commit introduces -
when using a backend with a custom ticker and doing manual render with
the display on, calling ecore_evas_manual_render() will not draw with
updated animator state.
Fix T5462
Again.
Really.
Engines that provide their own tickers may need to be able to provide the
time of the last tick even if they weren't sending ticks to EFL at the
time.
This is a feature added during freeze as it's necessary to resolve a bug.
ref T5462
When using the legacy API (and in fact also with the EO API) to
listen to mouse events (move, in, out...) on a window instead
of an actual evas object, some information was missing:
- buttons (bitmask of pressed buttons)
- prev.x/y (previous position)
This is because Evas had not handled the event yet at this
point, it was coming directly from ecore_evas with incomplete
information. This patch involves evas a little bit earlier, and
also fixes evas_events_legacy.c to have consistent values for
cur/prev canvas/ouput coordinates. See also 890a91785 and
484dae76e6. Those commits were making the pointer coord
a seat-based property (instead of canvas-based) but the event
should already have those proper values before converting to
a legacy struct. This patch restores the meaning of the DUP
macros, as I observed 4 different coordinates from the app side
(instead of just 2: prev and cur).
Thanks to Andy for reporting the original issue on the ML!
If the framespace size has changed and by accident (or in fact, by
design) the evas size + framespace size is equal to the size sent
by the X server, ecore_evas_x was skipping the resize event. This
patch adds a tracking of the framespace size so that we redraw the
canvas if it changed.
This will fix issues with the main menu (since it's in the framespace,
23 pixels tall with the default theme & scale).
Note that all this is partly because the ecore evas size is the size
without the framespace, so weird calculations are made during resize...
Ref T5482
Summary:
This completes the documentation for Ecore_Evas for all (non-deprecated)
APIs.
Note that ecore_evas_software_16_ddraw_new, ecore_evas_direct3d_new,
ecore_evas_gl_glew_new, and ecore_evas_sdl16_new are left undocumented
because while they're not declared as deprecated their implementations
are either missing or marked as obsolete or legacy. I suspect a few of
the remaining routines are likely also obsolete but I added
documentation anyway.
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4972
Small patch to fix misleading return value when
ecore_evas_aux_hint_val_set fails. In the above code, we will return
EINA_TRUE already if the aux_hints_set works, so this return value at
the bottom of the function should be EINA_FALSE.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch to support using Ecore_Evas_Interface_Wayland in order to
add support for setting auxiliary hints on a surface
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
1. The word "class" is a pain point with many languages where
it's a keyword. Type is a little better. Also, the property
was already named "device_type" and not "device_class".
2. Remove Efl.Input.Device.Sub_Class
It's not used inside EFL upstream codebase, and unlikely to
be used anywhere else (even in Tizen).
Hopefully no one used the Efl_ enum types. So far only the Evas_
types should be in used.
Ref T5540