[Webkit-unassigned] [Bug 145814] [Mobile Safari, WKWebView] increase DeviceOrientationEvent events emission frequency.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=145814

--- Comment #9 from Benjamin Poulain <benjamin at webkit.org> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150611/d16e49aa/attachment.html>