On 21/02/2013 09:51 PM, Ulisses Furquim wrote:
> Hi devilhorns,
>
> On Thu, Feb 21, 2013 at 6:47 PM, Chris Michael <devilho...@comcast.net> wrote:
>> On 21/02/2013 09:22 PM, Ulisses Furquim wrote:
>>>
>>> Hi,
>>>
>>> On Thu, Feb 21, 2013 at 6:13 PM, Chris Michael <devilho...@comcast.net>
>>> wrote:
>>>>
>>>> On 21/02/2013 08:45 PM, Ulisses Furquim wrote:
>>>>>
>>>>>
>>>>> Hi devilhorns,
>>>>>
>>>>>> Well, I don't see valgrind helping much in this situation as it is not
>>>>>> a
>>>>>> leak or crash or anything like that ... but in the spirit of
>>>>>> cooperation
>>>>>> ;)
>>>>>> I will run it when I get back to the office on Monday.
>>>>>
>>>>>
>>>>>
>>>>> Well, yes, the idea is to have a backstrace when it hangs. Attaching
>>>>> gdb and stopping it and getting a backtrace on both threads might be
>>>>> easier indeed.
>>>>>
>>>>> Regards,
>>>>>
>>>>
>>>> No worries. I'll try to sort that out on Monday.
>>>>
>>>> If you could provide some details wrt the async render process and what
>>>> wakes up the thread, that may help also.
>>>
>>>
>>> Well, the main thread sends commands to the render thread using the
>>> primitives in src/lib/evas/common/evas_thread_render.c for each
>>> canvas. The render thread has the code in that same file and wakes up
>>> as soon as a canvas has completed its list of commands for that frame
>>> and issues the final flush command. The render thread takes the list
>>> and starts issuing the callbacks and when it reaches the flush command
>>> it sends an async event to the main thread so it completes some steps
>>> like cleaning up data structures, issuing post render callbacks, for
>>> the sw_x11 it calls a function passed to evas_render_async() to update
>>> the regions in X, updates the cur for the objects and so on. Thus, if
>>> you see a stall then it *might* be that something is delaying the
>>> async event to the main thread to actually be sent or be received and
>>> processed.
>>>
>>> If you need any more insight on the code, just let me know.
>>>
>>> Regards,
>>>
>>
>> Ahhhh, I see now :) Thank You !!! Very insightful and helpful !! I believe I
>> may know what is causing the stall now...but will not know for sure until
>> Monday when I can run some tests....If my suspicions are correct then it is
>> fixable inside the engine code and not an issue w/ the evas async code.
>>
>> Basically, in the engine we have a frame callback that we listen on and the
>> compositor tells us when it has rendered that frame. (antognolli: NB: if
>> (!win->frame_pending))
>>
>> In the engine code, if we are still waiting for that frame to be rendered,
>> then we bypass/ignore any subsequent calls to evas_async_render...thus I
>> *think* that is the issue. We are waiting for the compositor to tell us it
>> has rendered that frame before we do any more calls to async_render. Because
>> the compositor has not drawn the frame yet, we are basically *stalling* the
>> evas render...That's the theory anyway ;) but I do not have the code in
>> front of me to double-check or test. Will look on Monday.
>>
>> Thanks again !! :)
>
>>From what you said and if I understood correctly, yes, that might be
> the problem indeed. And you cannot stall the main thread without
> consuming async events otherwise this might lead to other problems and
> not just the async rendering code. Thus you need to find a way to
> properly wait for the compositor telling you that

Well, in terms of Wayland, that is the "proper" way for the compositor 
to tell you its done rendering that frame.

  or maybe find
> another way of accomplishing that.
>

Exactly ;)

I'll investigate further and test a couple of theories on Monday. Thank 
you Very much for your insight and explaination. Very helpful !! :)

Cheers,
dh


> Regards,
>


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to