Hi, I'd like to understand how a port is supposed to implement this file. My understanding is that
1. setSharedTimerFiredFunction sets a function that the port should call. 2. setSharedTimerFireInterval is called by WebCore with a time interval. The port is supposed to call the function pointer set through setSharedTimerFiredFunction after this time interval is elapsed. If any timer is in progress, it should reset itself. 3. stopSharedTimer is called by WebCore. If this is called, any scheduled timer callback should not be called. Does it sound correct? The general understanding I have is that ThreadTimers.cpp does all the housekeeping of registered timers (like when each one should be called). We implement our View/WebView with a Tick() function that application is supposed to call (usually at 60 FPS). If we simply call the timer callback set in setSharedTimerFiredFunction inside the Tick(), do we run into any risk (For example, firing a timer too soon than it was scheduled)? On surface, that does not seem to be the case since ThreadTimers::sharedTimerFiredInternal() checks the nextFireTime of the timer that is supposed to be fired earliest. The only side effect I can see with this approach is that any timer set to fire with a frequency higher than the View::Tick() frequency will not fire at higher frequency but would end up in sync with the View::Tick() frequency. This also means that all the startOneShot(0) timers would end up triggering next "frame". Is this correct understanding? So if we have a View::Tick() running at 60 FPS that calls the shared timer function callback, does that seem alright (except the issues noted above)? In my local testing, I did not see anything wrong. I appreciate any answers. Thanks.
_______________________________________________ webkit-help mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-help
