Bug 145814 – [Mobile Safari, WKWebView] increase DeviceOrientationEvent events emission frequency.

• Component: WebKit2
• Status: RESOLVED FIXED

[Eugene But]

In iOS, Safari emits DeviceOrientation events at 20 Hz. Unfortunately this is too slow for any practical purposes. The main request for Safari and WKWebView is to increase the update rate to much higher (eg. 60 Hz, to be on par with Chrome). A custom API for triggering this behavior is totally fine for us.

rdar://21306756

[Eugene But]

Context:

We work on Virtual Reality Cardboard experience and want to support good head tracking in the browser for when we render content in Cardboard or Cardboard-like devices.

[Boris Smus]

Created attachment 254683 [details]
Increased sensor firing update frequency.

Can we increase the frequency further? My ideal would be 100 Hz (kMotionUpdateInterval = 0.01).

[Benjamin Poulain]

Comment on attachment 254683 [details]
Increased sensor firing update frequency.

View in context: https://bugs.webkit.org/attachment.cgi?id=254683&action=review

> Source/WebCore/ChangeLog:7
> +        Reviewed by Benjamin Poulain.

ahahahah :)

Normally, there is a default value here: "Reviewed by NOBODY (OOPS!)." which is replaced by the real value.

> Source/WebCore/platform/ios/WebCoreMotionManager.h:38
> -const float kMotionUpdateInterval = 0.05f;
> +const float kMotionUpdateInterval = 0.0166f;

Hum, I think something like this would look clearer: 1. / 60;

[Benjamin Poulain]

(In reply to comment #2)
> Created attachment 254683 [details]
> Increased sensor firing update frequency.
> 
> Can we increase the frequency further? My ideal would be 100 Hz
> (kMotionUpdateInterval = 0.01).

Can you explain a bit why it is important to have 100 Hz? The framerate is intentionally capped to 60 Hz on iOS.

For input events like touch or mouse, I understand why native apps use 120hz. The intermediate value can be used when drawing. For device orientation, I do not know why that's important.

Note that the iOS Gyro does support 100 Hz. My concern about sending many events is pages tend to perform an order of magnitude worse than the worse native app.

[Boris Smus]

Ok, totally agree that 1/60 is much clearer (updated the patch). The reason for getting a faster-than-render update loop is that in practice we'll need to do prediction of the position for better head tracking.

In VR, by the time we render using the last known head position, the head may have moved already. There may be N frames of delay between the input thread and the render thread. To address this, we can do better by predicting where the head will be N frames in the future based on historical movement. To do this, the more faster the data update rate, the better.

This paper describes some of the techniques in more detail: http://msl.cs.uiuc.edu/~lavalle/papers/LavYerKatAnt14.pdf

[Boris Smus]

Created attachment 254690 [details]
Cleaner frequency constant.

[Boris Smus]

Created attachment 254691 [details]
Fixed ChangeLog too :)

[WebKit Commit Bot]

Attachment 254691 [details] did not pass style-queue:


ERROR: Source/WebCore/ChangeLog:1:  ChangeLog entry has no bug number  [changelog/bugnumber] [5]
Total errors found: 1 in 2 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Benjamin Poulain]

(In reply to comment #5)
> Ok, totally agree that 1/60 is much clearer (updated the patch). The reason
> for getting a faster-than-render update loop is that in practice we'll need
> to do prediction of the position for better head tracking.
> 
> In VR, by the time we render using the last known head position, the head
> may have moved already. There may be N frames of delay between the input
> thread and the render thread. To address this, we can do better by
> predicting where the head will be N frames in the future based on historical
> movement. To do this, the more faster the data update rate, the better.
> 
> This paper describes some of the techniques in more detail:
> http://msl.cs.uiuc.edu/~lavalle/papers/LavYerKatAnt14.pdf

What do you think of:
1) In the DeviceMotionEvent, add a timestamp property that provide the time at which the event was emitted.
   On device, there is typically a delay ~1ms between the time an event gets on the run loop, and the time it hits JavaScript. It seems like having that information would be critical.
2) On the event, add an array with all the historical data received between 2 events.
   That way, we can call JavaScript 60 times a second but no information is lost. If there are additional data point, they would be in the array.

If that solves the problem, I suggest your make a proposal like this.

Rich Tibbett, the editor of the Device Orientation spec, is a really nice guy. You should contact him and see what is the best way to improve the spec.

[Benjamin Poulain]

Committed r185444: <http://trac.webkit.org/changeset/185444>

[Benjamin Poulain]

(In reply to comment #10)
> Committed r185444: <http://trac.webkit.org/changeset/185444>

Real commit is http://trac.webkit.org/changeset/185443, I fucked up the link.