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 ------------------------------------------------------------------------------ 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
