W3C home > Mailing lists > Public > public-geolocation@w3.org > August 2010

Re: Gyroscope/DeviceMotion events

From: Andrei Popescu <andreip@google.com>
Date: Tue, 3 Aug 2010 14:28:29 +0100
Message-ID: <AANLkTinBYkxvS7xUQfxBiGmi43CEoCEBqnkpBs=AH8F4@mail.gmail.com>
To: Dean Jackson <dino@apple.com>
Cc: public-geolocation@w3.org
On Tue, Aug 3, 2010 at 11:31 AM, Dean Jackson <dino@apple.com> wrote:
> 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.

Ok, let's add it then. I think both accelerometer and gyro data should
be on the same event.

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

Maybe, although, as I said, the flags' interaction with the
DeviceOrientation event can be quite confusing. I'm not sure.

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

If we go for option B, then I think we should have a single interval.
Or can you think of a use case when you'd want to specify different

As for the meaning of the interval, it would have to be a hint to the
implementation and no guarantees should be made that the interval is
actually respected. On Android, for example, we can only specify the
interval in terms of 4 constants:


Received on Tuesday, 3 August 2010 13:28:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:01 UTC