Cc: klausw@chromium.org Status: Available (was: Unconfirmed)
Thanks for the report. We're currently doing some hacky scheduling that doesn't go through Chrome's normal frame scheduling path in order to hook up the high accuracy pose data VR APIs give us without making getFrameData perform slow synchronous IPCs to get the pose.
We're working on making scheduling better and dealing with pose data differently, so this will get better in the future.
+cc klausw
In the short term we should probably just figure out how to get the NonPresentingGvrDelegate to listen to the BeginFrameSource and send VSyncs at the same time, though that won't totally solve the issue, as normal chrome scheduling still won't be blocked on vrDisplay rAF.
In the medium term if we get poses sent through shared memory, we can piggy-back off of the document rAF like we did back in M56 and still avoid the sync IPC.
Or maybe we should just piggy-back off document rAF now, and send new poses with each beginFrame, to be queued up in the renderer for the next rAF call... This would add a small amount of extra pose latency to magic window but would remove the performance differences between vrDisplay.rAF and window.rAF.
I guess the unfortunate thing here is that we'd have to add extra complexity to VrDisplay, which would need to have separate vsync logic for presenting and non-presenting.
Comment 1 by mthiesse@chromium.org
, May 19 2017Status: Available (was: Unconfirmed)