We encountered a deadlock case in ecore_evas_image_object in ecore_evas_buffer
that only happens if the ecore_evas_buffer has nothing changed to render,
though it's triggered to rendering.
See this normal scenario that is working fine as our intention.
being ecore_evas_render()
...
-> ecore_evas_buffer_prepare()
-> evas_object_image_data_get()
-> increment lock by backend engine. (egl/tbm ...)
-> render()
-> render_post()
-> _ecore_evas_buffer_update_image()
-> evas_object_image_data_set()
->decrement lock by backend engine (egl/tbm ...)
...
end ecore_evas_render()
The problem is, if the ecore_evas_buffer canvas doesn't changed at all,
render post will be skipped, it could lose the chance to unlock the image data.
Now the host can't render anymore since it's image source lost the lock.
@fix
so ecore_event_evas_shutdown() was getting called much more than
ecore_event_evas_init() - missing an init in the ee + img obj creator
in ecore evas. this adds it in and ensures in allocation failures we
dont over-init or shutdown too.
@fix
this is done in order to make ecore_event_evas_key_down work with this.
The function can be used to simulate interactions with a efl_ui_win. If
this is not added, then the user of ecore_event_evas_key_down needs to
differentiate between buffer engines and the rest of the engines.
Differential Revision: https://phab.enlightenment.org/D7361
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 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
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>
if buffer canvas is not image object, this needs to emit a move event
to be consistent with other engines
probably this should emit events in all cases, but adding for image buffers
this close to release seems potentially risky so I'll leave that for later
ref 4a691f79df
This fixes the following ERR message:
ERR<10589>:eina_safety /home/jpeg/e/core/efl/src/lib/ecore_evas/ecore_evas.c:3149
_ecore_evas_mouse_move_process_internal() safety check failed: cursor == NULL
To allow using the pageflip completion event to drive timing in the DRM
engine we need to know as soon as possible that a render has been after
a render has been considered if it will cause a page flip or not.
The fn_evas_changed callback sends this information.
Summary:
The window auxiliary hint is the value which is used to decide
which actions should be made available to the user by the WM. If you
want to set specific hint to your window, then you should check whether
it exists in the supported auxiliary hints that are registered in the
root window by the window manager.
Once you've added an auxiliary hint, you can get a new ID which is used
to change value and delete hint. The window manager sends the response
message to the application on receiving auxiliary hint change event.
A list of auxiliary hint within the Ecore_Evas has this format:
ID:HINT:VALUE,ID:HINT:VALUE,...
Reviewers: raster, cedric, seoz, Hermet
Reviewed By: raster
CC: cedric
Differential Revision: https://phab.enlightenment.org/D543
Summary: The window manager rotation allows the WM to controls the rotation of application windows. It is designed to support synchronized rotation for the multiple application windows at same time.
Reviewers: raster, seoz, cedric, Hermet
Reviewed By: raster
CC: cedric
Differential Revision: https://phab.enlightenment.org/D529
It is a very tricky things to get header order right on windows. Having that
order only in .c files simplify the work a lot. So let's try to do it with
Ecore_Evas after it rewrite and split into modules.
I add new example related with this. (ecore_evas_extn_socket & plug example)
ecore extn use this infrasturcture, server app and client app can communicate each other
later, this can be used to contorl access message
SVN revision: 83942
Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for
the .la, use the EFL_ macros to generate the contents to be used in
automake files.
There is a nasty bit that libtool will parse Makefile*.am and will not
get _DEPENDENCIES from _LIBADD and _LDADD if these are in
@REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The
contents of this is almost the same as _LIBADD or _LDADD with the
"_INTERNAL_" replacement name.
I hope the code will be result will be shorter and consistent as there
is less places to change when we add/remove dependencies.
Statistics are quite impressive (diffstat):
{{{
37 files changed, 663 insertions(+), 1599 deletions(-)
}}}
SVN revision: 82785
buffer is lightweight and dependency for many engines, merge it back
into core.
extn is a module on its own, and it's the only one linking to
ecore_ipc, no need to add that to ecore_evas.
minor cosmetic changes to configure to make output consistent.
SVN revision: 82648
Implementing support for loadables modules. It makes the engines been
loaded when they are needed. It not breakes the api, so each engine
still has its own api.
The implementation basically is:
* Functions that creates Ecore_Evas, for example
ecore_evas_software_x11_new, request to load its module and then get
the module's function to create the Ecore_Evas.
* The other functions such as \(.*\)_window_get from the Ecore_Evas
its interface and then call the appropriate method.
* As there is no unified interface to communicate with the engines
(not break api problem), all interfaces were declared in
ecore_evas_private.h
* Now the data necessary for each module is not declared in the
Ecore_Evas_Engine structure, instead of this, the struct has a void
pointer that is used by the modules.
* In this first moment engines as software_x11 and gl_x11 were put
together in the same module, but obviously exporting all the things
necessary.
SVN revision: 80280
Elyes HAOUAS
Hosang Kim
Hermet Park
Wonki Kim
Chris Michael
Carsten Haitzler
Marcel Hollerbach
Mike Blumenkrantz
Mike Blumenkrantz
Cedric BAIL
Woochan Lee
Jean-Philippe Andre
Guilherme Iscaro
Derek Foreman
Daniel Zaoui
Gwanglim Lee
ChunEon Park
Jihoon Kim
Cedric Bail
Jiyoun Park
Gustavo Sverzut Barbieri
Flavio Vinicius Alvares Ceolin