[webkit-dev] FW: SharedTimer<platform>.cpp related question

[Baldeva, Arpit]

Forwarding it to webkit-dev list in case anyone has ideas on this.

Thanks.

From: webkit-help-bounces at lists.webkit.org [mailto:webkit-help-bounces at lists.webkit.org] On Behalf Of Baldeva, Arpit
Sent: Wednesday, October 19, 2011 10:56 AM
To: webkit-help at lists.webkit.org
Subject: [webkit-help] SharedTimer<platform>.cpp related question

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20111020/563953a5/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20111020/563953a5/attachment.txt>