On 10/26/13 19:27, Rafael Antognolli wrote:
> On Sat, Oct 26, 2013 at 3:13 PM, Rafael Antognolli <antogno...@gmail.com>
> wrote:
>> Hey dh,
>>
>> On Tue, Jul 23, 2013 at 3:15 AM, Chris Michael - Enlightenment Git
>> <no-re...@enlightenment.org> wrote:
>>> devilhorns pushed a commit to branch master.
>>>
>>> commit cc596a358851e06f162dd3e8f75938c4b6395584
>>> Author: Chris Michael <cp.mich...@samsung.com>
>>> Date: Thu Jul 18 11:07:05 2013 +0100
>>>
>>> If the init count is >= 1, then we want to iterate (ecore_imf wayland
>>> module adds an extra init).
>> Why do we need to do that? If ecore_wl_init returns > 1, it means that
>> it was initialized already, and nothing will happen inside of that
>> function.
>>
>> Plus if we call wl_display_dispatch() when there's nothing to be
>> "dispatched", it will block until something else occurs. And this is
>> what is going on with elm tests, when we click on a test button and it
>> blocks until the mouse is moved, or a key is pressed, or whatever.
>>
>> I'm trying to understand why ecore_imf wayland module needs this, but
>> if that's the case, we could maybe add this dispatch inside the module
>> itself, instead of here, no?
> nvm, I just noticed that it's because of ecore_wl_registry_get and
> ecore_wl_globals_get.
Yes. Ecore_Imf wayland module needs those ... but really there is a
larger problem that needs addressing in ecore_imf (but that's another
story) ;)
> So, I think we need a better and more asynchronous way of init the wl
> backend. Maybe an Ecore event that, when emitted, we are sure that
> everything that depends dispatch things was done already?
> And, in the
> case of someone calls those functions before the event being received,
> THEN we can block waiting for the dispatch being finished? That would
> be similar to what I did in ecore_wl_screen_size_get.
Well, there is an event already there for this purpose. An "interfaces
bound" event gets raised ... but currenly on does so when compositor,
shell, and shm have been bound...easily changed tho.
dh
> I'll try to think about it carefully and see if I find a simple
> implementation. That would enable us to never block on init, and keep
> things that depend on the registry, global and display still working.
> And of course, remove this dispatch from the engine_new_internal code.
>
>>> Fix some formatting
>>>
>>> Signed-off-by: Chris Michael <cp.mich...@samsung.com>
>>> ---
>>> src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c | 2 +-
>>> src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c | 5 +++--
>>> 2 files changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git
>>> a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c
>>> b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c
>>> index e8a4570..1d5ac49 100644
>>> --- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c
>>> +++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c
>>> @@ -112,7 +112,7 @@ ecore_evas_wayland_egl_new_internal(const char
>>> *disp_name, unsigned int parent,
>>> ERR("Failed to initialize Ecore_Wayland");
>>> return NULL;
>>> }
>>> - else if (count == 1)
>>> + else if (count >= 1)
>>> ecore_wl_display_iterate();
>>>
>>> if (!(ee = calloc(1, sizeof(Ecore_Evas))))
>>> diff --git
>>> a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c
>>> b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c
>>> index fae0b4f..048d2c7 100644
>>> --- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c
>>> +++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c
>>> @@ -111,7 +111,7 @@ ecore_evas_wayland_shm_new_internal(const char
>>> *disp_name, unsigned int parent,
>>> ERR("Failed to initialize Ecore_Wayland");
>>> return NULL;
>>> }
>>> - else if (count == 1)
>>> + else if (count >= 1)
>>> ecore_wl_display_iterate();
>>>
>>> if (!(ee = calloc(1, sizeof(Ecore_Evas))))
>>> @@ -179,7 +179,8 @@ ecore_evas_wayland_shm_new_internal(const char
>>> *disp_name, unsigned int parent,
>>>
>>> wdata->parent = p;
>>> wdata->win =
>>> - ecore_wl_window_new(p, x, y, w + fw, h + fh,
>>> ECORE_WL_WINDOW_BUFFER_TYPE_SHM);
>>> + ecore_wl_window_new(p, x, y, w + fw, h + fh,
>>> + ECORE_WL_WINDOW_BUFFER_TYPE_SHM);
>>> ee->prop.window = wdata->win->id;
>>>
>>> ee->evas = evas_new();
>>>
>>> --
>>>
>>> ------------------------------------------------------------------------------
>>> See everything from the browser to the database with AppDynamics
>>> Get end-to-end visibility with application monitoring from AppDynamics
>>> Isolate bottlenecks and diagnose root cause in seconds.
>>> Start your free trial of AppDynamics Pro today!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>
>>
>> --
>> Rafael Antognolli
>
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
