<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>145814</bug_id>
          
          <creation_ts>2015-06-09 13:26:56 -0700</creation_ts>
          <short_desc>[Mobile Safari, WKWebView] increase DeviceOrientationEvent events emission frequency.</short_desc>
          <delta_ts>2015-06-10 23:40:07 -0700</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>WebKit2</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>iPhone / iPad</rep_platform>
          <op_sys>All</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords>InRadar</keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Eugene But">eugenebut</reporter>
          <assigned_to name="Nobody">webkit-unassigned</assigned_to>
          <cc>barraclough</cc>
    
    <cc>benjamin</cc>
    
    <cc>boris</cc>
    
    <cc>commit-queue</cc>
    
    <cc>dino</cc>
    
    <cc>mail</cc>
    
    <cc>sam</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1100771</commentid>
    <comment_count>0</comment_count>
    <who name="Eugene But">eugenebut</who>
    <bug_when>2015-06-09 13:26:56 -0700</bug_when>
    <thetext>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</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1100836</commentid>
    <comment_count>1</comment_count>
    <who name="Eugene But">eugenebut</who>
    <bug_when>2015-06-09 16:09:40 -0700</bug_when>
    <thetext>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.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1101132</commentid>
    <comment_count>2</comment_count>
      <attachid>254683</attachid>
    <who name="Boris Smus">boris</who>
    <bug_when>2015-06-10 15:25:46 -0700</bug_when>
    <thetext>Created attachment 254683
Increased sensor firing update frequency.

Can we increase the frequency further? My ideal would be 100 Hz (kMotionUpdateInterval = 0.01).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1101143</commentid>
    <comment_count>3</comment_count>
      <attachid>254683</attachid>
    <who name="Benjamin Poulain">benjamin</who>
    <bug_when>2015-06-10 15:46:20 -0700</bug_when>
    <thetext>Comment on attachment 254683
Increased sensor firing update frequency.

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

&gt; Source/WebCore/ChangeLog:7
&gt; +        Reviewed by Benjamin Poulain.

ahahahah :)

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

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

Hum, I think something like this would look clearer: 1. / 60;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1101150</commentid>
    <comment_count>4</comment_count>
    <who name="Benjamin Poulain">benjamin</who>
    <bug_when>2015-06-10 15:54:41 -0700</bug_when>
    <thetext>(In reply to comment #2)
&gt; Created attachment 254683 [details]
&gt; Increased sensor firing update frequency.
&gt; 
&gt; Can we increase the frequency further? My ideal would be 100 Hz
&gt; (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&apos;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.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1101165</commentid>
    <comment_count>5</comment_count>
    <who name="Boris Smus">boris</who>
    <bug_when>2015-06-10 16:49:03 -0700</bug_when>
    <thetext>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&apos;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</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1101168</commentid>
    <comment_count>6</comment_count>
      <attachid>254690</attachid>
    <who name="Boris Smus">boris</who>
    <bug_when>2015-06-10 16:52:21 -0700</bug_when>
    <thetext>Created attachment 254690
Cleaner frequency constant.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1101169</commentid>
    <comment_count>7</comment_count>
      <attachid>254691</attachid>
    <who name="Boris Smus">boris</who>
    <bug_when>2015-06-10 16:56:25 -0700</bug_when>
    <thetext>Created attachment 254691
Fixed ChangeLog too :)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1101173</commentid>
    <comment_count>8</comment_count>
    <who name="WebKit Commit Bot">commit-queue</who>
    <bug_when>2015-06-10 17:18:26 -0700</bug_when>
    <thetext>Attachment 254691 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.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1101177</commentid>
    <comment_count>9</comment_count>
    <who name="Benjamin Poulain">benjamin</who>
    <bug_when>2015-06-10 17:30:12 -0700</bug_when>
    <thetext>(In reply to comment #5)
&gt; Ok, totally agree that 1/60 is much clearer (updated the patch). The reason
&gt; for getting a faster-than-render update loop is that in practice we&apos;ll need
&gt; to do prediction of the position for better head tracking.
&gt; 
&gt; In VR, by the time we render using the last known head position, the head
&gt; may have moved already. There may be N frames of delay between the input
&gt; thread and the render thread. To address this, we can do better by
&gt; predicting where the head will be N frames in the future based on historical
&gt; movement. To do this, the more faster the data update rate, the better.
&gt; 
&gt; This paper describes some of the techniques in more detail:
&gt; 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.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1101194</commentid>
    <comment_count>10</comment_count>
    <who name="Benjamin Poulain">benjamin</who>
    <bug_when>2015-06-10 19:02:18 -0700</bug_when>
    <thetext>Committed r185444: &lt;http://trac.webkit.org/changeset/185444&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1101195</commentid>
    <comment_count>11</comment_count>
    <who name="Benjamin Poulain">benjamin</who>
    <bug_when>2015-06-10 19:02:53 -0700</bug_when>
    <thetext>(In reply to comment #10)
&gt; Committed r185444: &lt;http://trac.webkit.org/changeset/185444&gt;

Real commit is http://trac.webkit.org/changeset/185443, I fucked up the link.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>254683</attachid>
            <date>2015-06-10 15:25:46 -0700</date>
            <delta_ts>2015-06-10 16:56:25 -0700</delta_ts>
            <desc>Increased sensor firing update frequency.</desc>
            <filename>increase-deviceorientation-frequency.patch</filename>
            <type>text/plain</type>
            <size>1152</size>
            <attacher name="Boris Smus">boris</attacher>
            
              <data encoding="base64">SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi
Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDE4NTM2MikKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n
ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDEzIEBACisyMDE1LTA2LTEwICBCb3JpcyBT
bXVzICA8Ym9yaXNAc211cy5jb20+CisKKyAgICAgICAgSW5jcmVhc2VkIHRoZSBzYW1wbGluZyBy
YXRlIG9mIERldmljZU9yaWVudGF0aW9uRXZlbnQgZnJvbSAyMCBIeiB0byA2MAorICAgICAgICBI
eiB0byBtYWtlIGdvb2QgaGVhZCB0cmFja2luZyBwb3NzaWJsZS4KKyAgICAgICAgaHR0cHM6Ly9i
dWdzLndlYmtpdC5vcmcvYXR0YWNobWVudC5jZ2k/YnVnaWQ9MTQ1ODE0CisKKyAgICAgICAgUmV2
aWV3ZWQgYnkgQmVuamFtaW4gUG91bGFpbi4KKworICAgICAgICAqIHBsYXRmb3JtL2lvcy9XZWJD
b3JlTW90aW9uTWFuYWdlci5oOgorCiAyMDE1LTA2LTA5ICBDc2FiYSBPc3p0cm9nb27DoWMgIDxv
c3N5QHdlYmtpdC5vcmc+CiAKICAgICAgICAgW2NtYWtlXSBGaXggdGhlIHN0eWxlIGlzc3VlcyBp
biBjbWFrZSBwcm9qZWN0IGZpbGVzCkluZGV4OiBTb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9pb3Mv
V2ViQ29yZU1vdGlvbk1hbmFnZXIuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2ViQ29yZS9wbGF0
Zm9ybS9pb3MvV2ViQ29yZU1vdGlvbk1hbmFnZXIuaAkocmV2aXNpb24gMTg1MzYyKQorKysgU291
cmNlL1dlYkNvcmUvcGxhdGZvcm0vaW9zL1dlYkNvcmVNb3Rpb25NYW5hZ2VyLmgJKHdvcmtpbmcg
Y29weSkKQEAgLTM1LDcgKzM1LDcgQEAKIAogI2ltcG9ydCA8Q29yZU1vdGlvbi9Db3JlTW90aW9u
Lmg+CiAKLWNvbnN0IGZsb2F0IGtNb3Rpb25VcGRhdGVJbnRlcnZhbCA9IDAuMDVmOworY29uc3Qg
ZmxvYXQga01vdGlvblVwZGF0ZUludGVydmFsID0gMC4wMTY2ZjsKIAogQGludGVyZmFjZSBXZWJD
b3JlTW90aW9uTWFuYWdlciA6IE5TT2JqZWN0IHsKICAgICBDTU1vdGlvbk1hbmFnZXIqIG1fbW90
aW9uTWFuYWdlcjsK
</data>

          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>254690</attachid>
            <date>2015-06-10 16:52:21 -0700</date>
            <delta_ts>2015-06-10 16:56:25 -0700</delta_ts>
            <desc>Cleaner frequency constant.</desc>
            <filename>increase-deviceorientation-frequency-2.patch</filename>
            <type>text/plain</type>
            <size>1157</size>
            <attacher name="Boris Smus">boris</attacher>
            
              <data encoding="base64">SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi
Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDE4NTM2MikKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n
ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDEzIEBACisyMDE1LTA2LTEwICBCb3JpcyBT
bXVzICA8Ym9yaXNAc211cy5jb20+CisKKyAgICAgICAgSW5jcmVhc2VkIHRoZSBzYW1wbGluZyBy
YXRlIG9mIERldmljZU9yaWVudGF0aW9uRXZlbnQgZnJvbSAyMCBIeiB0byA2MAorICAgICAgICBI
eiB0byBtYWtlIGdvb2QgaGVhZCB0cmFja2luZyBwb3NzaWJsZS4KKyAgICAgICAgaHR0cHM6Ly9i
dWdzLndlYmtpdC5vcmcvYXR0YWNobWVudC5jZ2k/YnVnaWQ9MTQ1ODE0CisKKyAgICAgICAgUmV2
aWV3ZWQgYnkgQmVuamFtaW4gUG91bGFpbi4KKworICAgICAgICAqIHBsYXRmb3JtL2lvcy9XZWJD
b3JlTW90aW9uTWFuYWdlci5oOgorCiAyMDE1LTA2LTA5ICBDc2FiYSBPc3p0cm9nb27DoWMgIDxv
c3N5QHdlYmtpdC5vcmc+CiAKICAgICAgICAgW2NtYWtlXSBGaXggdGhlIHN0eWxlIGlzc3VlcyBp
biBjbWFrZSBwcm9qZWN0IGZpbGVzCkluZGV4OiBTb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9pb3Mv
V2ViQ29yZU1vdGlvbk1hbmFnZXIuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2ViQ29yZS9wbGF0
Zm9ybS9pb3MvV2ViQ29yZU1vdGlvbk1hbmFnZXIuaAkocmV2aXNpb24gMTg1MzYyKQorKysgU291
cmNlL1dlYkNvcmUvcGxhdGZvcm0vaW9zL1dlYkNvcmVNb3Rpb25NYW5hZ2VyLmgJKHdvcmtpbmcg
Y29weSkKQEAgLTM1LDcgKzM1LDcgQEAKIAogI2ltcG9ydCA8Q29yZU1vdGlvbi9Db3JlTW90aW9u
Lmg+CiAKLWNvbnN0IGZsb2F0IGtNb3Rpb25VcGRhdGVJbnRlcnZhbCA9IDAuMDVmOworY29uc3Qg
ZmxvYXQga01vdGlvblVwZGF0ZUludGVydmFsID0gMS4wZiAvIDYwLjBmOwogCiBAaW50ZXJmYWNl
IFdlYkNvcmVNb3Rpb25NYW5hZ2VyIDogTlNPYmplY3QgewogICAgIENNTW90aW9uTWFuYWdlciog
bV9tb3Rpb25NYW5hZ2VyOwo=
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>254691</attachid>
            <date>2015-06-10 16:56:25 -0700</date>
            <delta_ts>2015-06-10 16:56:25 -0700</delta_ts>
            <desc>Fixed ChangeLog too :)</desc>
            <filename>increase-deviceorientation-frequency-3.patch</filename>
            <type>text/plain</type>
            <size>1155</size>
            <attacher name="Boris Smus">boris</attacher>
            
              <data encoding="base64">SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi
Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDE4NTM2MikKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n
ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDEzIEBACisyMDE1LTA2LTEwICBCb3JpcyBT
bXVzICA8Ym9yaXNAc211cy5jb20+CisKKyAgICAgICAgSW5jcmVhc2VkIHRoZSBzYW1wbGluZyBy
YXRlIG9mIERldmljZU9yaWVudGF0aW9uRXZlbnQgZnJvbSAyMCBIeiB0byA2MAorICAgICAgICBI
eiB0byBtYWtlIGdvb2QgaGVhZCB0cmFja2luZyBwb3NzaWJsZS4KKyAgICAgICAgaHR0cHM6Ly9i
dWdzLndlYmtpdC5vcmcvYXR0YWNobWVudC5jZ2k/YnVnaWQ9MTQ1ODE0CisKKyAgICAgICAgUmV2
aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgKiBwbGF0Zm9ybS9pb3MvV2ViQ29y
ZU1vdGlvbk1hbmFnZXIuaDoKKwogMjAxNS0wNi0wOSAgQ3NhYmEgT3N6dHJvZ29uw6FjICA8b3Nz
eUB3ZWJraXQub3JnPgogCiAgICAgICAgIFtjbWFrZV0gRml4IHRoZSBzdHlsZSBpc3N1ZXMgaW4g
Y21ha2UgcHJvamVjdCBmaWxlcwpJbmRleDogU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vaW9zL1dl
YkNvcmVNb3Rpb25NYW5hZ2VyLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvcGxhdGZv
cm0vaW9zL1dlYkNvcmVNb3Rpb25NYW5hZ2VyLmgJKHJldmlzaW9uIDE4NTM2MikKKysrIFNvdXJj
ZS9XZWJDb3JlL3BsYXRmb3JtL2lvcy9XZWJDb3JlTW90aW9uTWFuYWdlci5oCSh3b3JraW5nIGNv
cHkpCkBAIC0zNSw3ICszNSw3IEBACiAKICNpbXBvcnQgPENvcmVNb3Rpb24vQ29yZU1vdGlvbi5o
PgogCi1jb25zdCBmbG9hdCBrTW90aW9uVXBkYXRlSW50ZXJ2YWwgPSAwLjA1ZjsKK2NvbnN0IGZs
b2F0IGtNb3Rpb25VcGRhdGVJbnRlcnZhbCA9IDEuMGYgLyA2MC4wZjsKIAogQGludGVyZmFjZSBX
ZWJDb3JlTW90aW9uTWFuYWdlciA6IE5TT2JqZWN0IHsKICAgICBDTU1vdGlvbk1hbmFnZXIqIG1f
bW90aW9uTWFuYWdlcjsK
</data>

          </attachment>
      

    </bug>

</bugzilla>