immersive web WG -- 27 Aug 2019

<trevorfsmith> forget agendum 4

<cwilso> scribenick: NellWaliczek

ada: Please star all the new repos so you can follow the conversation

Figure out what the additive blend mode should do with alpha values

cabanier: XRLayer has settings to initialize it, but fewer than the actual WebGL context
... Specifically missing perserveDrawingBuffer and premultiplied alpha

<ada> Note for reference /agenda command works in all repos in the immersive-web github organisation.

cabanier: If a canvas's context was inititalized with those two values in a way that's incompatible with the XRWebGLLayer
... propsing that the layer should fail to construct

bajones: some background here
... To actually implement preserve drawing buffer, there would be an extra copy on underlying systems which force the buffer to clear
... at the time, we decided to not allow this and people cheered
... the XRWebGLLayer is separated from the the canvas so this decision shouldn't create a problem
... I don't know if the same approach should applied to the premultiplied alpha
... IIRC this was a late addition to WebGL and I didn't think much about it
... though it does seem to there is a defacto thing that everyone is doing here anyway
... if this isn't actually agreed, we should get that surfaced asap.
... I don't know if there's an inherent conflcit or not because the actual display is in two different places

cabanier: I don't know either. some people wanted to draw directly into the buffer

someone from oculus: I can look into it

cabanier: it would be bad if not explicitly stated because the see through ar hardware is assuming premultiplied alpha

bajones: generally we should go with the webgl defaults

cabanier: default is true

bajones: let's document in the spec that we are expecting premultiplied

cabanier: are you not worried about a preexisting context that is targeted for both

<Zakim> NellWaliczek, you wanted to ask about inline

<inserted> scribenick: samdrazin

Nell: expectations for inline?
... in context for creating WebGL layer, context must have preserved drawing buffer false?

bajones: no, frame buffer allocated by WEbXR will have PDB be false, but actual buffer can be overridden

nell: waht happens with default frame buffer for inline?

bajones: spec says all values passed in get overridden by whatever the canvas is already doing
... may be some unexpected behavior, ie content on headset vs other screen
... clear path to fix if this isnt desired

nell: same thing applkied to pre-multiplied alpha? we will add to spec: for immersive, buffer you get back will expect pre-mult alpha?

bajones: yes, we will likely not provide a way to specificy somethign for pre-mult alpha (unless vendors request).

nell: we'll ignore all default values, or just some?

bajones: we'll have same defaults as creating a canvas. we'll ignore context creation params sent to canvas
... not aware of when we'd inherit from when the canvas is created
... to discuss more offline

<blair> I think it's Nell's connection

<blair> You are clear, she's breaking up for me

<cwilso> scribenik: cabanier

<cabanier> scribenick: cabanier

<Zakim> kip, you wanted to mention that pre-multiplied alpha makes it easier to use one code path for both additive and alpha blended displays

kip: I want to make 1 point. premultiplied alpha makes it easy to do additive displays

ada: we already discussed this a bit

bajones: I think everyone already agreed to this
... when we cycle through the frameloop, we present a new frame each time
... and it should be ok to clear the buffer at the beginning on each frame
... some platforms automatically clear
... is anyone concerned that we state that the UA always clears the buffer at the beginning of the frame

artem: on our platform it's a requirement

bajones: do we want to guarantee that the clear happens?

NellWaliczek: did we say what the clearcolor should be?

bajones: it should be opaque black unless there's alpha in which case it's transparent black

NellWaliczek: in the core spec it should say this
... in the AR spec it should change it

bajones: I don't think so. It's the alpha value
... the core text can specify the behavior from alpha

NellWaliczek: in the AR spec we should say we must specify alpha

bajones: additive displays will work if there is no alpha
... we should figure out what the behavior must be there

NellWaliczek: we can write the spec text concurrently
... if there are limitations for buffer alpha for AR sessions

bajones: does anyone oppose this idea??

<Zakim> kip, you wanted to suggest that if no alpha is present, then content would be interpreted as additive even on passthrough displays

kip: rather than requiring, the browser could interpret if it doesn't get what it expects
... if content didn't provide alpha, you could treat it as additive

NellWaliczek: let's move that to the AR repo

kip: ok. That's just one example. I prefer the spec as describing the content
... perhaps with that context we can avoid issues and make people successful

ada: why transparent black? and . not magenta
... it would make it clear that you're doing something wrong

bajones: there's a reasonable chance that clearing to black is the native behavior
... and the whole point is to save work and clearing to magenta would introduce extra work
... and there are case where the default color as black is the desired behavior
... usually you want a black background anyway
... no device will clear to another color than black by default

<Zakim> kip, you wanted to mention if we are clearing, we may also need to define how depth is cleared

kip: when a depth buffer is present we should make clear what happens then

bajones: yes, all buffers (ie stencil) should be cleared

ada: what would the depth buffer clear to?

kip: there used to be a reason to have a different depth for every frame
... most people likely clear it to 0

bajones: most people do it to 1
... since it's the furthest value

kip: yes!

bajones: the inverted depth range is still useful
... opengl doesn't like it since it -1 to 1
... we can specify it clears to 1
... if people want more control, we can add it to the renderstate

kip: what would happen if someone inverted the values?
... should we invert the default then too?

bajones: the worst case is that we preclear with the wrong value and they'd have to clear it again

NellWaliczek: let's cut it short and put a PR up

<trevorfsmith> +1

<bajones> +1

<NellWaliczek> +1

<ada> +1

<kip> +

Spatial tracking on inline sessions when viewed within an XR headset

NellWaliczek: I want to make sure that we future proofed ourselves
... I talked to bajones about this
... and we think that the spec text is already ok

<samdrazin> scribenick: samdrazin

<NellWaliczek> https://github.com/immersive-web/webxr/issues/756

nell: sanity check: where we'd tied # of views wouldnt limit our options w/ diorama views
... when creating diorama, on flat browser (either just browser, or running within 3D env), you could bolt infinitely large shoebox to page
... essentially a hole cut out you can look thru, see different angles
... Magic Leap supports this in their browser (outside WebXR). might be nice to include within WebXR ,esp for inline sessions
... do we need a different reference space?
... what is the implication for the number of views
... Brandon convinced me: diorama would not have any implications of stereoscopic viewing
... something stereoscopic comes back to what is known intrinsically at session creation time
... no relationship between ref space and # views. rather, num views defined at session creation
... existing ref space types would need to be compatible with this behavior
... Does anyone have any issues with this, or need clarification?

rik: qq: will we allow spatial tracking for inline?

nell: we do already, but not by default. one of requested features (can be market opt or req).
... UAs can decide at session creation time whether or not they want to create (and whether or not to prompt)
... guidance: inline sessions (independent of tracking) should not require tracking at first, and anotehr can be created wiht tracking
... and then terminate non-tracking one after the tracking one gets created

rik: that will not be required, right?

nell: correct. devs can request. if platform cannot support, nbd. session will be rejected
... wanted to confirm whether immersive browsers needed to support this, and wanted to confirm whther diorama (as a feature) has implications for number of views
... it doesnt. will write this up
... FYI this is not a current feature, but will be added as a proposal

ada: last agenda item: Behavior of window.requestAnimationFrame and window.requestIdleCallback when presenting -

nell: issue #225
... been around for a while. refresh everyone on this, if opinions exist, please share them. Kip had AI?
... who will take point for resolving this (before end of sept)?

bajones: comments from way back (May '17) discussing some options, but no consensus reached
... kip followed up with more info, no new info that changes our fundamental approach (how window rAF impacts our rAF)
... eg mobile device inserted into viewer that obscures page, window rAF will not fire if ours is
... rafael's comment aligns with this. headset rAF should be able to fire at different rate than window rAF
... would be good to close this out. any concern anyone has with this behavior (esp stopping rAF by session start)?

<trevorfsmith> Closing it out sounds (with rAF not pumping when not visible) good to me.

ada: as web dev, rAF not pumping implies window not visible is correct.

bajones: only concern on this point: this content is produced by page, then some elemetn of page is visible, even if this isn't intuitive
... generally, agree to not pump it at that point

<inserted> scribenick: samdrazin

<Zakim> NellWaliczek, you wanted to point out consistency may be an issue

nell: only concern (not opposing): those who test on desktop / mobile may be surprised by differing behaviors
... worry that not pumping rAF on mobile will make things not work on mobile
... other side, if we do rAF, this hurts battery/takes CPU hit
... esp a challenge on mobile. I see cases on both sides

bajones: to that point (desktop vs mobile) this is addressed in separate issue (spec 4.3) example covers thsi exact topic
... it is admittedly awkward. tests across devices will have some issues
... not sure what we can do to avoid this, all bad options
... see Example #3 in the spec (section 4.3)

nell: should we add spec text that indicates 1 more window rAF will be pumped to help immunize devs from making this mistake?
... back at MS, we'd see content that made this assumption, but different UAs behaved differently
... consistency around when this stop would happen might be usefuol

bajones: understand the impulse. concerned bc this implies we need symmetric 1-frame-more session side
... seems weird to pump after the session has ended
... if we spend and dont pump the window any further (last window rAF), will naturally kick in after session

nell: time is up

ada: we can revisit this topic next mtg

bye bye

- DRAFT -

immersive web WG

27 Aug 2019

Attendees

Contents

Figure out what the additive blend mode should do with alpha values

Spatial tracking on inline sessions when viewed within an XR headset

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output