Hi, On Thu, Feb 21, 2013 at 7:01 PM, Chris Michael <devilho...@comcast.net> wrote: > 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.
Ok, I didn't mean that. I meant that this is not the proper way of waiting inside Evas for this notification from Wayland compositor (if you are doing what I think you are doing :-). > 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 !! :) You're welcome. :-) Regards, -- Ulisses Furquim ProFUSION embedded systems http://profusion.mobi Mobile: +55 19 9250 0942 Skype: ulissesffs ------------------------------------------------------------------------------ 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
