On 21/02/2013 05:58 PM, Ulisses Furquim wrote: > Hi devilhorns, > > On Thu, Feb 21, 2013 at 2:55 PM, Chris Michael <devilho...@comcast.net> wrote: >> On 21/02/2013 05:04 PM, Ulisses Furquim wrote: >>> >>> Hi Rafael, >>> >>> On Thu, Feb 21, 2013 at 1:46 PM, Rafael Antognolli <antogno...@gmail.com> >>> wrote: >>>> >>>> Hey Ulisses, thanks for answering! >>> >>> >>> You're welcome, man. > >>>> On Thu, Feb 21, 2013 at 1:19 PM, Ulisses Furquim <ulis...@profusion.mobi> >>>> wrote: >>>>> >>>>> Hi Rafael, >>>>> >>>>> On Thu, Feb 21, 2013 at 9:50 AM, Rafael Antognolli >>>>> <antogno...@gmail.com> wrote: >>>>>> >>>>>> Hey guys, >>>>>> >>>>>> I've been trying to debug a problem that only happens on the Wayland >>>>>> backend, both SHM and EGL, but I have no more ideas. >>>>>> >>>>>> tl;dr: >>>>>> The elm_flip widget doesn't animate when using the FLIP_PAGE_* >>>>>> animation modes. However, it works perfectly with FLIP_CUBE_* and >>>>>> FLIP_ROTATE_*. The strange thing is exactly this: both the normal flip >>>>>> page animation and the interactive flip page animation are not working >>>>>> only on Wayland. >>>>>> >>>>>> On elementary_test, there's a test called Flip Page, which I think >>>>>> that Raster wrote, and contains all the code to do this animation by >>>>>> itself. That one works perfectly. >>>>>> >>>>>> The elm_flip widget seems to be based on that code and do the same, >>>>>> but it doesn't work on Wayland! >>>>>> >>>>>> >From my tests, I noticed that (on the SHM engine) the recently written >>>>>> buffer from each animation frame has the same content (same pixels) >>>>>> before being pushed/attached to the surface, so it does not seem to me >>>>>> a problem of marking damaged areas or swapping the buffers. I also >>>>>> checked most functions from this path and it all seems to be being >>>>>> called correctly, exactly the same as other things being rendered. >>>>>> >>>>>> I *think* that the problem is somewhere on the rendering path, but I >>>>>> can't tell what since this rendering path is on software_generic, >>>>>> being used both by wayland_shm and software_x11. >>>>>> >>>>>> That makes me think that the problem may be due to some change done >>>>>> during the async render integration, though I also forced the >>>>>> software_x11 backend to use the synchronous path, using >>>>>> ECORE_EVAS_FORCE_SYNC_RENDER=1. It still works correctly, and follows >>>>>> the same path as the wayland_shm. >>>>> >>>>> >>>>> Does it work or not when you force sync rendering? And are you using >>>>> async, really? These engines are supposed to be using only sync >>>>> rendering AFAIR. >>>> >>>> >>>> I'm sorry, I guess I wasn't clear. >>>> >>>> The wayland backend is not using async rendering at all. What I meant >>>> is that I was testing the software_x11 engine, and I forced it to use >>>> the sync path too, just to make sure that it was not a problem related >>>> to that and correctly compare it to the wayland backend. Anyway, the >>>> software_x11 engine worked on both cases (sync and async), while the >>>> wayland backend doesn't work (it only uses sync at the moment). >>> >>> >>> Ok, so the same code paths in software_generic work for sw_x11 both >>> sync and async. The problem seems to be engine specific then. >>> >>>>> You really need to check if you are using any async path which I >>>>> doubt. You should have that only if you are calling >>>>> evas_render_async() to render a frame. >>>> >>>> >> >> Yes, with the async patches, the wayland_shm engine does use >> evas_render_async. >> >> >>>> Agreed, wayland_shm backend is not using any async path, although >>>> Devilhorns has some patches about to be landed that would make use of >>>> the async path. Anyway, his patches also don't fix the issue. >>> >>> >>> I see. :-/ >>> >>> -- Ulisses >>> >> >> I should note: The patches for wayland_shm implement Async rendering in the >> same way that the software_x11 (and other engines) do. Also, when it is not >> "stalled" in the async rendering path, then things do render just fine with >> async enabled. It's just that every x seconds, it "stalls".... I am thinking >> that *something* is not waking up the render thread when needed, but not >> knowing much about the async rendering, I could not sort it out (and have >> not found time to dig into it further yet).... > > Please, if you could run on valgrind and check what's happening would > be great. I can try to help you on that but I need more information. > > Regards, > > -- Ulisses >
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. 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
