Re: [w3c/gamepad] Vibrate feature for Gamepad (#19)

I only have a tiny dog in this hunt, but it seems to me that we should cover both rumble and force feedback in a haptics API.  MIcrosoft's DirectInput API lets you design an effect and upload it into the device and then start it with a subsequent API call.  https://msdn.microsoft.com/en-us/library/windows/desktop/ee417563(v=vs.85).aspx

Regarding the abuse issue, I don't think the API would be very friendly if it could throw up a "Page Unresponsive"-like dialog if the JavaScript has crossed some internal spam threshold on the update calls.  

I looked at how the Web Audio API handles throttling the audio updates, and they use the onaudioprocess event to signal when a buffer has started to play.  The developer can use onaudioprocess to double-buffer their audio buffers and play infinite length raw or generated audio streams.  

Would there be any utility in having a "onhapticsprocess" event that could be used to similarly double-buffer updates sent to the rumble motors?  Perhaps spammy calls to the haptics API's could be dropped, and only the latest update sent to each motor before onhapticsprocess fires would be processed by the device?

I like the Haptics naming too!

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/19#issuecomment-238698142