[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





--- Comment #6 from Ojan Vafai <ojan at chromium.org>  2012-11-02 14:51:43 PST ---
(In reply to comment #5)
> (In reply to comment #4)
> > 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.

You don't like the idea of throttling when audio is muted? Specifically, I was thinking this could work more like requestAnimationFrame. It gives the callback an argument of the actual time so that it can know if some callbacks got skipped and catch up appropriately.

It's admittedly a less developer-friendly API, but the benefits of not using your CPU for audio the user isn't hearing seem possibly worth it.

I'm not wed to this. Just thinking out loud.

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

Oh, I see. callbackAtTime makes more sense then.

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