One blocker to be aware of here is that other services that use this type of shared memory (like Gamepad) have their buffer reading code in content/renderer (https://cs.chromium.org/chromium/src/content/renderer/gamepad_shared_memory_reader.h) rather than blink/modules (where all the renderer VR code resides) simply because some of the atomic types necessary for safe read/write live in device (https://cs.chromium.org/chromium/src/device/base/synchronization/shared_memory_seqlock_buffer.h) and including them from blink would be a layering violation.

I think there was an issue open to make this available in base instead, but I can't find it right now. In any case, either that would have to be fixed first OR we'd have to introduce a new dependency on content/renderer.

amp, billorr: FYI on the above comment.

Is there a key reason why vr rendering lives in blink/modules?  Should we consider moving that up to a location that can better depend on on content/renderer?

@amp, The WebVR API lives in blink/modules, it needs poses to hand out to javascript.

I am slightly concerned that we'll need to wake up the device thread more frequently to get poses more often.  We should measure power numbers too to ensure we don't regress.

I'm unsure why the current design leads to stale poses though - we send a vsync with the latest pose, and it results in an animation frame callback to the javascript right away.  The javascript may do something instead of rendering at that point, but its the sites fault.

@billorr, two reasons for stale poses:

- if JS is running slow, a vsync including its pose will get queued up for processing, and by the time the app finally gets around to using it it'll be older than ideal.

- less significantly, if an app can do work including rendering setup that doesn't depend on the exact camera position, i.e. physics or game logic, it could do that in its rAF callback before fetching the pose. That could make the pose ~10ms fresher in some cases.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Removing Blink>WebVR component and assigning to Blink>WebXR