Now when dealing with pointer types, we will not get pointer to
pointer semantics in callbacks and eina_promise_owner_value_set
for Eina_Promise.
It will work as expected:
Eina_Promise_Owner* promise = eina_promise_add();
void* p = malloc(sizeof(T));
eina_promise_owner_value_set(promise, p, &free);
The call to eina_promise_then steals the first ref'count, so it is
possible that the promise is freed after the eina_promise_then,
so we need to eina_promise_ref before eina_promise_then.
Summary:
Implemented interface Efl.Gfx.Buffer functions bufer_map/unmap for Efl.Canvas3D.Scene.
Added function e3d_drawable_texture_rendered_pixels_get to module evas_gl_3d
to getting pixels from FBO. Added wrappers for functions
e3d_drawable_texture_rendered_pixels_get and e3d_drawable_texture_id_get
to have possibility call it through engine functions.
Reviewers: cedric, Hermet, raster, jpeg
Reviewed By: jpeg
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3978
So... I had issues with evas-fb engine which was massively leaking,
one image per frame.
After investigating a bit with @cedric on IRC, the reference count
of the cache entries was always 2 before the engine dropped.
So, for each frame with an animation, we could never drop a cache
entry, leading to a trumendous amount of memory leaking.
Now for non-async rendering, we copy the behaviour of
evas_render_pipe_wakeup() which is called in async-mode,
and actually drops a reference in the cache entry.
Fixes T3763
Not sure if this test case is really good, but it was
necessary to prove that input event refeed can work from
application side. This is a feature that should work
but shouldn't be used :)
This does:
1. Forward keyboard events from evas to win
2. Allow feeding external input events
Input events can be faked by apps by simply forging
eo objects of the proper type (key or pointer evt) and
calling eo_event_callback_call().
Such events will be forwarded to the internal Evas, and
some bool flags prevent infinite refeeding loops.
efl_event_dup() returns fake events for this to work.
@feature
This reverts commit ac5a0b7e79.
I added assert(pd == sd) in the modified code and couldn't find
anything suspicious. The proper class is used in eo_data_scope_get().
I also can't find a crash or a bug currently in hover. I know there
was a problem earlier, but that was fixed in 3092e08a83.
Now, if there is still a problem, we should check it carefully.
Pinging @cedric
Cedric revert patch 6f7608befd same days
ago.
<quote Cedric>
Your patch 6f7608befd did break elemines
which does relly on the proper index to be given to it. I think
Edje_Edit should be fine and use the index if no name is provided (See
edje_load.c around L1180). In all case this was clearly an ABI break and
needed to be reverted.
</quote Cedric>
So now edje_cc not guarantee name for part items. This is bad, because
edje_edit use item name for access to item attributes. If item have not
name we cann't get it attributes, because edje_edit compare the given
name with part items name from edj-file, strcmp dislake NULL args.
For now I see one way mark all edje_edit_part_item* APIs as deprecated
and add new APIs for manage part items by index.
For clearly and history:
The eason for revert - https://phab.enlightenment.org/D3820
The proposed solution - https://phab.enlightenment.org/D3907
We can not assume that the elementary parent will be also somewhere in the eo parent
hierarchy. We need to explore both when doing an eo_provider_find in elementary for it
to be really useful.
Apparently, libudev is not thread-safe which means we cannot use Eeze
for getting the udev but rather need to actually use libudev, so those
revert needs to be reverted.
This reverts commit 354bc66d0d.
A better fix to not use libudev functions has been pushed previously,
so there is no need to add an extra dependency on libudev as we use
Eeze already.
This reverts commit 9d429a7c1f.
As we already link to Eeze and use it throughout this code, there is
no point in adding an extra dependency on libudev itself when we can
just use Eeze functions to get what we need. This is a better fix for
T3712
@fix
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
lib/elementary/.libs/lib_elementary_libelementary_la-elm_cnp.o: In function `wl_data_offer_accept':
/usr/include/wayland-client-protocol.h:893: undefined reference to `wl_proxy_marshal'
/usr/include/wayland-client-protocol.h:893: undefined reference to `wl_proxy_marshal'
collect2: error: ld returned 1 exit status
Based on a patch by aerodynamik. Thanks!
Fixes T3398
Elput is using udev directly so we need to amke sure we link against it.
lib/elput/.libs/lib_elput_libelput_la-elput_input.o: In function `_elput_input_init_thread':
/<<PKGBUILDDIR>>/src/lib/elput/elput_input.c:317: undefined reference to `udev_new'
/<<PKGBUILDDIR>>/src/lib/elput/elput_input.c:326: undefined reference to `udev_unref'
Patch by aerodynamik. Thanks!
Fixes T3712
This lets me narrow down the remaining cases of pointers across the EFL.
The void pointers will later need to be reevaluated on per-case basis and
replaced appropriately where possible/feasible.