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
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
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.
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
Hermet Park
Mike Blumenkrantz
Cedric Bail
Gustavo Sverzut Barbieri