On 21/02/2013 09:22 PM, Ulisses Furquim wrote: > Hi, > > On Thu, Feb 21, 2013 at 6:13 PM, Chris Michael <[email protected]> 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 !! :) Cheers, dh ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
