There was a corner case which gl_sync_draw_done is set to -1. So send
comp_sync_draw_size_done when the gl_sync_draw_done is not 1. It can be -1 or 0.
This is a manual cherry-pick from tizen.org.
Thanks to original author Jiyoun Park.
commit 4be6c821df4ccd418dbe44f7e6fecbcd7dd66d74
Author: Jiyoun Park <jy0703.park@samsung.com>
Date: Thu Jul 4 18:04:11 2013 +0900
fix lockup issue (N_SE-44214)
because this sync draw done cannot be send
Change-Id: Id05978e925d5b44d6ca9af0a1684bbb255b9ec5b
in SOME cases a wm may deny a resize request entirely and keep the
window size the same. it does so with a configurenotify of the SAME
size as before. problem is we never passed this onto the app with a
resize callback of the original size before request to the new size.
this does that now.
cherry-pick me!
Git log should be enough for the credit :)
This code was merged into efl upstream by devilhorn's aggressive synchronization between efl upstream and tizen.
But that commit didn't have the author's credit.
However We will never forget the contribution of Gwanglim Lee <gl77.lee@samsung.com>.
when the window alpha mode is changed, the x window is re-created.
but if the window is going on the show state(not visible yet but waiting for visible from xserver) this window never be visible.
so here it make the window visible also if the window is going on the visible state.
This reverts commit 9bfb730ff5.
wrong! on deiconify this will now FORCE a ACTIVATE request to the wm
(which asks the wm to focus the window/hilight it and make it active.
might switch desktops or whatever). this is wrong. de-icoifying a
windows does NOT mean ALSO activating it!. the log message also doesnt
say what "go back to normal state"... means.... do they expect/INSIST
windows MUSt be focused after de-iconification? that's wrong as it's a
window management FOCUS policy, not something to do in the lib.
We don't want to execute any of the function below if t is NULL. Its not
only about strdup but alsa ecore_x_netwm_name_set which might dereference it.
CID 1039400
- ecore_evas_pixmap_visual_get
- ecore_evas_pixmap_colormap_get
- ecore_evas_pixmap_depth_get
Assign interface functions for above when creating the new interface.
When creating the pixmap, store the visual and colormap for later
retrieval.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
- Add "pixmap" structure to engine_data.
- Free the front and back pixmaps when the ecore_evas gets freed.
- On resize, drop the backing pixmap if size is different.
- Before we render, check pixmap size vs EE size and create new
backing pixmap if needed.
- After we have rendered into the backing pixmap, flip it to the
front so that any calls to "pixmap_get" will return the proper one.
- Add pixmap_new_internal code (the actual guts for all this)
NB: These can be used to create an internally double-buffered
ecore_evas that renders to a pixmap (not a window).
Signed-off-by: Chris Michael <cp.michael@samsung.com>
When moved mouse among two objects having cursor set,
EVAS_CALLBACK_MOUSE_OUT and EVAS_CALLBACK_MOUSE_IN are fired.
I observed that evas_object_del in callback of EVAS_CALLBACK_MOUSE_OUT
calls EVAS_CALLBACK_MOUSE_IN
so that newly added cursor object was detached.
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
no - not planning a backport of this at this stage. small thing. maybe
backport (and chlog/news) if this doesnt cause any new issues?
SVN revision: 82549
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
Daniel Juyung Seo
Carsten Haitzler
ChunEon Park
Sebastian Dransfeld
Chris Michael
discomfitor
Michal Jagiello
Stefan Schmidt
Mike Blumenkrantz
Sebastian Dransfeld
Ryuan Choi
Cedric BAIL
Jiyoun Park
Cedric Bail
Jiyoun Park
Gustavo Sverzut Barbieri
Leandro Pereira
Flavio Vinicius Alvares Ceolin