Meeting minutes
@Manishearth: No one is speaking
Now Chris is...
<cwilso> yes, I am now?
https://github.com/immersive-web/webxr/pull/1088
<Manishearth> alrght i can't hear
Delaying for resolution of technical audio issues
webxr#1088 Allow caching various objects (take 2); To discuss how people feel about unconditionally caching, and whether there's anything that can be done about poses [Manishearth]
Manish: Every animation frame creates a bunch of objects
<Manishearth> https://github.com/immersive-web/webxr/issues/1010
Manish: causes problems with GC. Can these objects be reused from frame to frame?
Start with XRViewport, XRFrame objects and a bunch others
… Current PR only caches XRViewport when viewport does not change
… This might break content (e.g., boolean) that expects the objects to be deleted
… Should this be mandated or a UA choice? It has some impact for content.
Discussion...
<crickets>
Manish: Any allergic reactions provided it's an animation frame and viewport doesn't change?
Rik: Anything in HTML spec that allows an API to return the same object?
Manish: DOM tree is singular. There are APIs that return a specific object or something new.
Rik: APIs shouldn't impact/observe/etc GC behavior
Manish: This PR doesn't change/observe GC.
Manish: getElementByTagName may return the same object. This is OK as long as the return is not dependent on GC
Leonard: Discussion primarly based on "may" vs. "must" in determining how the UI needs to behave.
Leonard: Also note GC == garbage collection
Manish: XRFrameObject is always the same. XRViewport is the same until Viewport changes
Ada: Might anyone have a h/w issue with this?
Manish: No. Might be difficiult to determine if there is a viewport change if floating point, but currently integer
Ada: Recommends that the PR remains open until others get a chance to review it
Manish: Agrees
<Manishearth> https://github.com/immersive-web/webxr/issues/1085
webxr#1085 One big `secondary-views` opt-in, or an opt-in per secondary view scenario?
Manish: This written by Alex. Added secondary views capability. Used if provided or generated if not available.
… different types supported: 1st person, 3rd person, quad (2 views/eye).
… Manish & Brandon position is one big opt-in for everything with a flag indicating view type
Rik: A 3rd person would be not "head" attached
Manish: Correct. The view would be someplace else. e.g., over the shoulder, etc. Generally 3rd person view
… requires rendering of the body & head. 1st person is (usually) just body.
Rik: More for VR rather than AR. Is that an issue for definition?
Manish: No, not currently defined.
<Zakim> kip, you wanted to mention that 1str person views are often a wider FOV and have smoothed out motion for VR
Kip: Streaming frequently uses 1st person with wide FOV and low-pass to remove motion
Manish: Opt-in already exists. Secondary views are generally not good when browser created.
Rik: Eye tracking system may causes problems with rendered scene
Manish: Issue is for opt-in
Leonard: Any issues with accessibility, especially for someone with only one functioning eye
Manish: No.
Ada: No other issues, no other comments...
Meeting complete.