Re: Gyroscope/DeviceMotion events

Hi Dean,

On Tue, Aug 3, 2010 at 2:16 AM, Dean Jackson <dino@apple.com> wrote:
> Following on from the thread last week and comments from Maciej, here's a new proposal for the movement events in Device Orientation.
>
> Actually, I'm presenting some alternatives. I don't have strong opinions either way, but I've already started on implementation, so the earlier the feedback the better. I think we'll do something like C+D even if the standard doesn't support it. Option A without B is the smallest change to the specification. If I had to choose, I'd pick B to replace the existing AccelerometerEvent and the proposal in A.
>
> A. Gyroscope Event
>
> This is similar to the Accelerometer Event.
>
> event.type = "gyroscope"
>
> interface GyroscopeEvent : Event {
>
>    readonly attribute double? xRotationRate;
>    readonly attribute double? yRotationRate;
>    readonly attribute double? zRotationRate;
>    readonly attribute double? interval;
>
>    void initGyroscopeEvent(in DOMString type,
>                                in boolean bubbles,
>                                in boolean cancelable,
>                                in double xRotationRate,
>                                in double yRotationRate,
>                                in double zRotationRate,
>                                in double interval);
> }
>
>
> B. Device Motion Event
>
> This comes from Maciej's proposal to have a single event cover both pieces of hardware.
>
> interface DeviceMotionEvent : Event {
>
>    readonly attribute double? xAcceleration;
>    readonly attribute double? yAcceleration;
>    readonly attribute double? zAcceleration;
>    readonly attribute double? accelerometerInterval;
>
>    readonly attribute double? xRotationRate;
>    readonly attribute double? yRotationRate;
>    readonly attribute double? zRotationRate;
>    readonly attribute double? gyroscopeInterval;
>
>    void initDeviceMotionEvent(in DOMString type,
>                                in boolean bubbles,
>                                in boolean cancelable,
>                                in double xAcceleration,
>                                in double yAcceleration,
>                                in double zAcceleration,
>                                in double accelerometerInterval,
>                                in double xRotationRate,
>                                in double yRotationRate,
>                                in double zRotationRate,
>                                in double gyroscopeInterval);
>    }
>
>

I prefer this option B, too. However, it'd be good to see a use case
so we can fully understand the problem we're trying to solve here.


> C. Testing for hardware support
>
> Something on the navigator object that tells the author what the hardware supports.
>
> readonly attribute bool supportsAccelerometer;
> readonly attribute bool supportsGyroscope;
>

Maybe it's better to have these on navigator.deviceOrientation rather
than directly on navigator.

However, I still think we don't need these. The DOM event model is
asynchronous so listening for a "not supported" event is probably not
that much overhead. I'm not sure it's worth expanding the API just for
this.

Also, how do these flags work with the DeviceOrientation event, which
uses data from multiple sensors? Should we have flags for all possible
types of hardware and let the user test for all combinations that
could be used to obtain device orientation?

> D. Allow the user to specify sampling intervals
>
> window.accelerometerInterval = 0.1; // 10 updates a second
> window.gyroscopeInterval = 0.1;
>

What happens if these are set to different values?

Thanks,
Andrei

Received on Tuesday, 3 August 2010 09:29:33 UTC