The implementation contains three main classes:
The following diagram shows the typical usage flow:
Support for the SensorTypes defined by the Mojo interface on Windows is summarized below:
SensorType | Sensor GUID |
---|---|
AMBIENT_LIGHT | SENSOR_TYPE_AMBIENT_LIGHT |
ACCELEROMETER | SENSOR_TYPE_ACCELEROMETER_3D |
LINEAR_ACCELEROMETER | * |
GYROSCOPE | SENSOR_TYPE_GYROMETER_3D |
MAGNETOMETER | SENSOR_TYPE_COMPASS_3D |
ABSOLUTE_ORIENTATION_EULER_ANGLES | SENSOR_TYPE_INCLINOMETER_3D |
ABSOLUTE_ORIENTATION_QUATERNION | SENSOR_TYPE_AGGREGATED_DEVICE_ORIENTATION |
*The LINEAR_ACCELEROMETER sensor type is provided by implementing a low-pass-filter over the values returned by the ACCELEROMETER in order to remove the contribution of the gravitational force.
The “Sensor GUID” column specifies the names of the sensor type GUIDs used to provide data for a SensorType. Any SensorType not mentioned by this table are not supported on Windows.
The overall sensor backend design on Windows remains the same (as detailed in section 3). The classes which take a direct dependency on the ISensor API have their interfaces abstracted out and reimplemented with Windows.Devices.Sensors:
This allows the other classes, which are agnostic to the underlying API, to interchangeability use the ISensor vs. Windows.Devices.Sensors implementation. This is advantageous as the two implementations live side by side.
The Windows.Devices.Sensors APIs do not currently support thresholding, but is coming in a future release of Windows. This means a (slight) performance degredation will occur if the Windows.Devices.Sensors APIs are used since the ISensor implementation does utilize thresholding. The Chromium backend will switch to use the ISensor implementation on versions of Windows that do not have WinRT thresholding support and will use the Windows.Devices.Sensors implementation for those that do.
Please refer to platform_sensor_provider.cc.
The overall Windows.Devices.Sensors design is the same as the current design detailed in section 3 except the classes that take a dependency on the ISensor API have been reimplemented with these new classes:
The existing PlatformSensorReaderWin class will be pulled out into its own interface in platform_sensor_reader_win_base.h.
The existing (ISensor) PlatformSensorReaderWin32 class and new (Windows.Devices.Sensors) PlatformSensorReaderWinrt class inherit from this interface so both classes can be interchangeably used with the ISensor/Windows.Devices.Sensors agnostic PlatformSensorWin, which simply consumes the PlatformSensorReaderWinBase interface.
Since there are several Windows.Devices.Sensors sensor functions which are identical between the different sensor types, an abstract class encapsulates the common functionality. Please refer to platform_sensor_reader_winrt.h.
The new Windows.Devices.Sensors sensor implementation will be hidden under a new Chromium feature flag. If this flag is enabled and the system meets the Windows version, then the Windows.Devices.Sensors path will be used for sensors. Otherwise, the ISensor path will be used.
While the modernization changes are being made, this flag will be kept as base::FEATURE_DISABLED_BY_DEFAULT
. Afterwards, experimentation will be used to enable this flag by default for a subset of the population. Once we have confidence the new implementation is reliable, then the flag will be moved to base::FEATURE_ENABLED_BY_DEFAULT
for everyone.
Below are the two main areas where reliability issues may occur, metrics will be put in place to measure them:
GetDefault()
.add_ReadingChanged()
.This metric will be compared with the existing ISensor failure rate to define the measure for success.
No performance metrics will be put in Chromium. The reason is twofold:
The performance delta of the Windows.Devices.Sensors implementation was a +0.47% total system CPU increase. This should drop to a zero or negative delta with the real Windows.Devices.Sensors implementation that supports builtin thresholding.
The modernization changes will be broken down into several incremental changes to keep change lists to a reviewable size: