On Mon, Nov 8, 2010 at 11:33 PM, Rafael Antognolli <antogno...@profusion.mobi> wrote: > 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). > > 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.
Well, the select() syscall always have a price, but I don't think it's that high. Effectively, the situation you describe with double timers will become: webkit event: add timer select -> timer expires relayout, webkit requests repaint: add idler select || run-idlers Thus it is quite simple and should not introduce any delays. There are different ways to investigate that, from logging at ecore (maybe need more printf) to a quick hack into webkit changing requests to always be timeout==0 (will run immediately as select will not block). -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ 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
