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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Nov 2 14:44:29 PDT 2012


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





--- Comment #5 from Chris Rogers <crogers at google.com>  2012-11-02 14:45:53 PST ---
(In reply to comment #4)
> 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?

One of the most interesting reasons for having this is so that there is no throttling.

> 
> 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.

I don't know if there's any reasonable way to prevent people from abusing it.

> 
> 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?

But it *is* a time in the time-coordinate system of the AudioContext.  If you look carefully at the Web Audio API specification, then you can see that these times are used extensively.  For example, there are AudioParam methods called "setValueAtTime()", etc.

> 
> 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.

We already have a time-system that's well established in the Web Audio API, so we know that this value is in terms of AudioContext.currentTime (which is in double-precision seconds)

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


More information about the webkit-unassigned mailing list