On Mon, 8 Nov 2010 23:33:46 -0200 Rafael Antognolli <antogno...@profusion.mobi> said:
> On Mon, Nov 8, 2010 at 10:04 PM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Mon, 8 Nov 2010 19:21:16 -0200 Rafael Antognolli > > <antogno...@profusion.mobi> said: > > > >> Hi guys, > >> > >> I have a problem implementing some timers inside WebKit. For some > >> animations, it adds a timer to relayout stuff, and this timer should > >> start in a few milliseconds, but this is smaller than the ecore > >> frametime. And timers added with ecore_timer_add just start on the > >> next main loop (when ecore will see that they expired). > >> > >> Does anyone have an idea of how to fix/workaround this? > > > > it's behaving just as expected. if timeout is so small that time from timer > > add to next main loop run is less than timeout... then yes next loop should > > see it instantly expire the timer. as such you'd need a bit more detail on > > what you are doing, but i suspect what you want is a timer that is longer > > than 1 animator timeframe as if u are animating.. you dont want a re-layout > > until the animation is done... maybe (and then delete and add the timer per > > frame). if this isn't what you want... then why not just re-layout at the > > same time as animating - you'd pay the price of rendering the anim and then > > doing the layout per frame anyway. combine them for a lower overall cost. > > The problem is the way that WebKit reports its animation. It schedules > a relayout of the page (for example that one that I just linked in my > previous email) using an ecore_timer for that. The time used for this > is very small, so that the animation runs as fast as possible (200 fps > on some ports of webkit). eek. timer used for animation itself? thats rather bad. thats why animators exist. so everything in the gui moves on a frame at the same time and at the same framerate. things like glib dont have a concept of animators - thus timeout > Once this relayout is processed (the timer expires and the callback is > called), then webkit reports that we need to repaint some areas of the > page. These repaints are also delayed to be processed later on an > idler or in the smart_calculate method. > > I believe that all this infrastructure of lazy repaints and lazy > relayout is making it too slow, thus the timer seems the easier place > to cut some time, since the idler and the smart_calculate callbacks > are not delayed by one frametime. i don't think so. it may add some latency - but it in general should perform better as you get to batch up state changes together and avoid re-rendering a small state change many times when you could batch it with other changes too. ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
