immersive web WG -- 10 Sep 2019

<ada> Thank you for setting up the agenda atsushi_!

<ada> What is happening at the moment?

<ada> Is someone talking to the group or is that background noise?

<LocMDao> sorry

<bajones> No worries!

<ada> scribenick: Leonard

scribe Leonard

Ada: TPAC next week ==> no WebEX meeting next week. Meeting will be in Japan -- all day

TAG Feedback: Should supportsSession resolve with a boolean? - From the TAG feedback for the WebXR API

Ada: Agenda: https://github.com/immersive-web/administrivia/blob/master/meetings/wg/2019-09-10-Immersive_Web_Working_Group_Teleconference-agenda.md
... #1 TAG Feedback

<kip> https://github.com/immersive-web/webxr/issues/824

<Manishearth> https://github.com/immersive-web/webxr/issues/824

Brandon: Feedback from TAG -- Should supportsSession resolve with Boolean? (https://github.com/immersive-web/webxr/issues/824)
... A function that returns a promise should return the same way as the promise is resolved.
... If the function is has* or is* should return T/F. Currently the function rejects if it is not available. This can be extended to
... other session functions defined in the spec. Rejects should be reserved for really serious problems (h/w failures, really bad parameters...)
... Not really interested in re-evaluating other promises in the spec, but this one is faily minor. It is a breaking change and if desired, should be done soon.

Mounir: Supports leaving as is because of the high cost for all existing applications

Brandon: That is a valid point. Not too many WebXR experiences online. Primary ones are example and other experimental mostly dealing
... with Chrome origin.
... How many other APIs follow this pattern and resolve to FALSE to indicate negative case?

Sam: On Chrome origin: There are about 100 signed up with ~26K sessions, 4-5K clients over the last ~5 days

Brandon: Origin trial is based on an older version of API ("broken" wrt to current)
... This change could be difficult to detect by developers because it is slightly hidden

Kip: Support of change. Asked locally about change and get feedback. A promise should be rejected if it the promise can't be done.
... If a question is asked, then it should be answered if possible; rejected if not answerable.
... A number of APIs appear to agree with this mechanism.

Brandon: Likes Kit
... 's explanation and how to determine rejection/provide response

Piotr: This is the right pattern to follow, but is it worth the effort to make the change?

Rik: Alternative? remove supportSession and create new API to handling things the "correct" way

Brandon: Not a fan of launching a new API to replace a deprecated feature. But does think there is value at breaking API so that it is clear
... that things changed. Doesn't like parallel versions in a new API

LocMDao: Agree with change (at least in the long run). Has 4 projects that would probably break, but willing to deal with it as long as this is not a regular occurrence.

<Zakim> klausw, you wanted to ask if we do change this, can we batch with other changes (if any) to avoid further churn?

Klaus: Make all breaking changes at once (and soon). Concerned about support for the process.

Brandon: Agree with concern. Wants to make it before any browsers ship with current API. If change were made today, it would probably not make Chrome 78.
... [revised by someone] Almost certain
... Mozilla is probably the same. WG needs to determine if breaking change is suitable at this point

Ada: Is there likely to be other breaking changes from TAG feedback?

Brandon: No idea at present. Hope that this is the primary breaking change.

<trevorfsmith> +1

Poll time: +1 for do change; -1 no change

<ada> +1

<bajones> -1

<alcooper_Google> -1

<kip> +1

<cabanier> +1

<bialpio> -1

<samdrazin> -1

<mounir> -1

<Manishearth> +1

<klausw> -1

<Art> +1

<LocMDao> +1

Ada: Poll is too even to call.

<trevorfsmith> Is it? I read it as everyone but Google thinks the change should be made.

Brandon: Suggest no action at this time. Discuss during TPAC with TAG in room, especially to find out if there are other breaking changes.
... Willingness to do this depends on number of breaking changes from TAG.

Ada: TAG meeting will be Monday PM

Agenda #2: Feature Policy should not control exposure of navigator.xr (https://github.com/immersive-web/webxr/issues/823)

<bajones> https://docs.google.com/document/d/1RZTL69JsTxoJUyXNnu_2v0PPILqrDpYW3ZxDjMAqQ-M/edit?usp=sharing

Brandon: Platform has moved away from controlling the availability of feature.
... doesn't feel it would be productive to read and make decision during call. Need to discuss at TPAC.

Mounir: Like to have a summary of document posted by Brandon

Brandon: Just reject promise. This is not a breaking change in Chrome. Would not be a breaking change for browsers that hide the attribute.

Agenda #3: Additive Blend Mode (https://github.com/immersive-web/webxr-ar-module/issues/14)

WHoops. Scratch the above

Agenda #3: Revisit transient input sources & XRInputSource.targetRaySpace (https://github.com/immersive-web/webxr/issues/819)

<bialpio> issue: https://github.com/immersive-web/webxr/issues/819

<scribe> <unknown>: Expose event that notifies application of input sources. Piggy-back on event for indicating input source is available.

UNKNOWN_SPEAKER: it also seems to add complexity to rest of spec. Difficult to implement, especially for hit testing.

Above from Piotr

Piotr [bialpio]: Proposed a solution that separates the two concepts with separate events

Brandon: Transient events: touch screen, voice activation, etc. Edge cases that most of the time appiles to inline session.
... trying to avoid input sources that might happen or never dies

Piotr: Concerned about time and longevity

Brandon: Supporting this concept makes portions of API more complex. Nell thinks that an existing event could create a subscription so
... tracking events could be handled

Piotr: Trying to understand the complexity for something that should be simple. Need support for arbitrary arrays.

Brandon: Existing APIs (ARCore/ARKit) use to have a limition. Thinks that the limitation has been lifted.

Piotr: Concern about optional portions of the spec and lack of uniform implementations

Conversation continues: Concern about delay (missing) information from point of subscription to receiving first data.

Manish: Possible to have a general transient source event?

Piotr: Might work.

Agenda #4: Additive Blend Mode (https://github.com/immersive-web/webxr-ar-module/issues/14)

<klausw> https://github.com/immersive-web/webxr-ar-module/issues/14#issuecomment-528618770

Manish: See comment link above. Issue with additive devices. Is/is not pre-multiply alpha? Can it be requested?

<Manishearth> https://github.com/immersive-web/webxr-ar-module/issues/14#issuecomment-529595422

Manish: Need to specify how do AR additive layers work.

<Zakim> klausw, you wanted to say additional comments

Klaus: Thinks no one wants to use non-pre-multiply alpha for AR. Should be a property of the default frame buffer
... How should developer notification happen?

Brandon: Existing pre-multiply flag applies to default canvas. WebGL does not work that way.

Rik: Recommends closing this issue and creating a new one that just addresses the open issue.

Brandon and Manish supports that position

Ada: If that is done, please tag with F2F so it can be handled next week.

LocDao: Demos at TPAC, does time need to be requested.

Ada: Create an issue in Administrative repositiory to request time (applies to everyone)

Brandon: WG has time during W3C demo time to explain to everyone

Ada: Please submit demo requests
... Meeting adjurned 1:02 PM PDT

- DRAFT -

immersive web WG

10 Sep 2019

Attendees

Contents

TAG Feedback: Should supportsSession resolve with a boolean? - From the TAG feedback for the WebXR API

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output