[Webkit-unassigned] [Bug 70061] Feature request: a way to schedule callbacks without relying on setTimeout

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=70061


Ojan Vafai <ojan at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jamesr at chromium.org,
                   |                            |ojan at chromium.org,
                   |                            |simonjam at chromium.org




--- Comment #4 from Ojan Vafai <ojan at chromium.org>  2012-11-02 14:39:08 PST ---
What's to stop people using this the same way they do setTimeout and eating all your cpu/battery with background tabs? I guess we expect people to mainly use it for audio, so we don't want to throttle it anyways?

I suppose if we end up giving some UI to disable audio for a tab or, if the system volume is muted, we could throttle this API the way we do setTimeout for background tabs. That'd be kind of neat actually. Would be great if we could do this from the initial launch of the API to prevent people abusing this as a generic timer API.

Bikeshed nit: callbackAtTime reads to me as something that would take a time (e.g. since the epoch) to callback at. How about just calling it setTimeout?

audioContext.setTimeout(callback, delay);

Do we want the delay to be in milliseconds or something more fine-grained? In other APIs the way we dealt with more fine grained was to have it still be milliseconds, but allow decimal values.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.