Re: [w3c/gamepad] Move vibrationActuator to the main spec (PR #190)

@nondebug commented on this pull request.



> +          Promise<boolean> pulse(double value, double duration);
+        };
+      </pre>
+      <dt>
+        <dfn>pulse()</dfn> method
+      </dt>
+      <dd>
+        <p>
+          <code>pulse()</code> applies a <var>value</var> to the actuator for
+          <var>duration</var> milliseconds. The <var>value</var> passed to
+          <code>pulse()</code> is clamped to limits defined by the actuator
+          type. The returned Promise will resolve <code>true</code> once the
+          pulse has completed.
+        </p>
+        <p>
+          Repeated calls to <code>pulse()</code> override the previous

I think the only implementation of `pulse` is in Meta Quest Browser. We should find out how it behaves and write the spec to match that implementation as closely as possible.

I looked at the original PR (https://github.com/w3c/gamepad/pull/32) and didn't see any discussion of whether the promise returned by pulse should ever do anything but resolve to true. Maybe @toji remembers?

Personally, I would want the promise returned by `pulse()` to resolve to true only if the effect played for the entire duration without being pre-empted. I expect apps will want to chain multiple calls to `pulse()` to make more complex effects. If one of the pulses is pre-empted, apps should be able to detect that and avoid playing the subsequent chained pulses.

So, I would say `p1` should be resolved with false after the second call to `pulse()`. We shouldn't reject in this case because pre-empting an effect is not an error.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/pull/190#discussion_r1406956412
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/pull/190/review/1751703964@github.com>