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

@kg how blocked is your DOM thread that event-driving a signal to update the motor intensity would add perceptible latency?  The fire rate of a JavaScript event can be set to whatever frequency makes sense for the browser vendor/device.  Regarding your example, a user pressing buttons is input, rate-limited by the device and speed of human hands.  Haptics is output, rate limited by ... the writer of the spec?  browser vendors?  device drivers?  

I hadn't considered DoS was an issue with haptics.  Any decent browser/OS/device driver set is going to protect the system against abuse like that.  What I'm concerned about is the web developer sending noise to the device because they don't know how to program.  By explicitly telling the developer "it's okay to update haptics now" by giving them an event to subscribe to, we can impose some order on them and take any guesswork out of when they should program the thing.  Just like outputted raw audio wave data flow control is achieved via the onaudioprocess event, I'm suggesting we would benefit from giving a similar flow control via events to haptics.

Giving developers an event is about helping them organize their thoughts, asking them to pick out the best signal to send to a motor based on what's happened recently in their simulation, etc.  If they still want to spam like maniacs, that's fine, we can ignore superfluous signals and they'll get noise on the device; but at least we can point them to the event when they complain that their code doesn't work right.

Automatically triggered haptics coupled to button presses also sounds like a really useful concept to include in the API for those applications that can use it.  Please add that too, @luser!

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