Re: [w3ctag/design-reviews] HTMLVideoElement.requestAnimationFrame() (#429)

My take is that the requestAnimationFrame design has mostly stood the test of time, apart from the overlong name. (And on that point, consistency/familiarity is more valuable than creating a new shorter name for new APIs that share the same semantics.)

In particular, here are a comparison with other paradigms:

- Promises are for one-and-done events. Although "the next animation frame" is a one-and-done event, and it could be useful for some cases to provide a `nextFrame` promise, my impression is that many cases benefit from a "call me every frame" API, for which callback-accepting works well. Emulating this by re-registering for the nextFrame promise, repeatedly, seems a bit roundabout.

- Streams (or async iterators) are not a good fit, because they represent streaming chunks of data that you are pulling from some source, and for which you never want to miss an occurrence. If you stop pulling from a stream, the data will buffer up inside the stream, until you start pulling again. In contrast, if you stop watching for animation frames, and then start again, you don't want to first have to work your way through a backlog of all the animation frames that happened while you were paused.

- Events (i.e. `EventTarget`) seem like a conceptual and semantic fit, but somehow... a bit heavyweight. They do have the right semantics: a broadcast from a central authority; subscribe/unsubscribe at leisure; repeated occurrence; etc. They could definitely work, and perhaps if we were starting from scratch we would consider an `"animationframe"` event on `Window`/etc. However, I suspect optimizing away all the extra machinery here would be frustrating for implementers, given that animation frames are frequent, and generally involved in animations or game loops, which need to be fast. Events have bubbling/capturing, `Event` objects, cancelation, etc. The `Event` object creation in particular seems tricky.

I'd be interested to hear others' perspectives on an `"animationframe"` event, and in particular how bad the optimizability concerns are, or if there are other concerns besides optimizability. But in general, even if it is a bit more conceptually parsimonious to use events here, in practice I think promoting certain occurrences like animation frames (`requestAnimationFrame`), timer intervals (`setInterval`), and idle callbacks (`requestIdleCallback`) to their own dedicated callback-accepting functions is OK.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/429#issuecomment-558850179