On Fri, Jan 18, 2013 at 12:45 AM, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > On Thu, Jan 17, 2013 at 1:11 PM, Leandro Pereira <lean...@profusion.mobi> > wrote: >> Hey, >> >> Here are some numbers that show that the async renderer is actually >> saving us time. These numbers can be obtained by yourself, by building >> Evas with EVAS_RENDER_DEBUG_TIMING defined and setting/unsetting the >> ECORE_EVAS_FORCE_SYNC_RENDER environment variable. >> >> This number is the measure, in ms, of the time spent during the Evas >> rendering function. The average value is calculated every 100 calls. >> >> One can clearly see that the asynchronous renderer frees up a lot of >> time in the main thread, in some cases using 10% of the time the >> synchronous renderer needed: >> >> ⮀ export ECORE_EVAS_FORCE_SYNC_RENDER=1 > [...] >> *** sync render: avg 1.754684ms min 0.486945ms max 3.843055ms >> *** sync render: avg 1.853960ms min 0.900002ms max 7.829068ms >> *** sync render: avg 2.597078ms min 0.549895ms max 25.936982ms > [...] >> ⮀ unset ECORE_EVAS_FORCE_SYNC_RENDER >> *** async render: avg 0.356258ms min 0.113084ms max 1.723979ms >> *** async render: avg 0.357304ms min 0.174066ms max 1.776023ms >> *** async render: avg 0.339344ms min 0.165109ms max 1.570926ms > > Yes, that's the kind of gain we expected from async render. As there > is no magic, you end doing MORE work to delegate to the thread, but > you have more predictable time spend on the main thread (min closer to > max, average is more constant).
The problem with this is that the added overhead is likely to increase power consumption. That's why we still have some optimization to do and async rendering open us a lot of possible speed improvement. For desktop use it's already a clear win in my opinion. > As the async render will "drop" frames per design (it will keep queue > full, but will not stop to render all requested frames, effectively > dropping some render() calls at no visual loss), your application will > always behave more smoothly, being able to interact with user input > more often. > > As for the predictable part, it's still not fixed in time, but we can > determine the time it will spend on the main thread > > - Async: > - Main Thread: depends on number of objects > - Render Thread: depends on number of objects AND output size > - Sync: main thread depends on number of objects AND output size > > Test hint: one can induce slowness by running with valgrind. The async > version behaves more smoothly than the other :-) > > Win! \o/ Is E17 usable under valgrind now ? :-D Just kidding... wait I should try that ! -- Cedric BAIL ------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
