Re: Gyroscope/DeviceMotion events

Hi Andrei,

On 03/08/2010, at 7:29 PM, Andrei Popescu wrote:

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

A use case for gyroscope? Or a use case for having both gyroscope and accelerometer at the same time?

Games are a pretty simple example. You might want to detect both the rotation of the device as well as movement along the axes. eg. a car game with twist to turn, pull towards you to slam on the brakes. You might want to detect these at the same time.

Anyway, gyro support is the main request here. I'm not too fussed about how it is exposed.

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

Yes, indeed.

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

It's not about overhead, it's more about ease of use. Most JS libraries test for a bunch of features at startup. It's weird to do this through an async call when the implementation knows the result immediately. It would be like having to provide callbacks for each branch of a conditional, even though the evaluation happens right away.

It also adds to the implementation, which has to return a null event. Yeah, it's trivial :)

I don't really care too much. I just think it is more convenient.


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

The hardware probably has no issue with different sampling rates, but the problem is the event. This is fine if we have separate events, but in option B it's confusing. What would you give for the device that is sampling slower when the faster device changes?

Maybe it is best to have only one interval, or choose option A.

Dean

Received on Tuesday, 3 August 2010 10:32:19 UTC