Consider using AbortController/AbortSignal instead of cancelRequestAnimationFrame

[kenchris]

Current API

  long requestAnimationFrame(XRFrameRequestCallback callback);
  void cancelAnimationFrame(long handle);

So something like:

dictionary XRFrameOptions {
  AbortSignal? signal;
}
void requestAnimationFrame(XRFrameRequestCallback callback, XRFrameOptions);

And usage:

const controller = new AbortController();
const signal = controller.signal;
requestAnimationFrame(callback, { signal });

controller.abort();

[mkeblx]

What are benefits of this approach for WebXR?

[toji]

Thanks for the suggestion! We've discussed using AbortController in other areas of the API, and certainly I think if we find a need for cancellable promises we'll be happy to make use of them. requestAnimationFrame is something of a special case, though, because we've done some negotiation with other parts of the web platform to ensure that it meshes nicely with window.requestAnimationFrame and can become part of a more generic interface that encapsulates both cases in the future if needed.

TL;DR: We're unlikely to see XR rAF change in format much because it's intentionally retaining compatibility with window rAF. I'm sold on using AbortController elsewhere, though.