Hi Rafael, On Thu, Feb 21, 2013 at 1:46 PM, Rafael Antognolli <[email protected]> wrote: > Hey Ulisses, thanks for answering!
You're welcome, man. > On Thu, Feb 21, 2013 at 1:19 PM, Ulisses Furquim <[email protected]> > wrote: >> Hi Rafael, >> >> On Thu, Feb 21, 2013 at 9:50 AM, Rafael Antognolli <[email protected]> >> 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. > > 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 ------------------------------------------------------------------------------ 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
