Add XRCompositor language to accomodate monoscopic displays

[cabanier]

• clarified stereo
• fixed some typos

Closes #68

[Manishearth]

Hmm. This might be confusing, it might be worth erroring if these are used instead of mono?

Alternatively, we can perhaps rename these to not be "stereo" but instead be "views" where they each have the number of subrects equal to the number of views, and we can have getViewport()-esque stuff to get viewports instead of requiring right-left and top-bottom. It seems very weird to me that the core spec is super flexible on this but layers hardcodes the choices.

This would also properly solve #114

[cabanier]

Hmm. This might be confusing, it might be worth erroring if these are used instead of mono?

No, we don't want to error out because then mono experiences will crash unless the author specifically accommodates them.

Alternatively, we can perhaps rename these to not be "stereo" but instead be "views" where they each have the number of subrects equal to the number of views, and we can have getViewport()-esque stuff to get viewports instead of requiring right-left and top-bottom. It seems very weird to me that the core spec is super flexible on this but layers hardcodes the choices.

I agree that stereo doesn't feel right but views is also confusing.
Maybe Natural, all or default?

[Manishearth]

yeah I don't quite care about the naming :)

It seems like we should just have "mono" vs "natural" and natural is laid out however the UA wants, using something like getViewport(). If we do this are the horizontal and vertical variants necessary? I.e. does the user still need the ability to request a particular arrangement?

[cabanier]

yeah I don't quite care about the naming :)

It seems like we should just have "mono" vs "natural" and natural is laid out however the UA wants, using something like getViewport().

Should I change it to natural or should we bring it to the group?

If we do this are the horizontal and vertical variants necessary? I.e. does the user still need the ability to request a particular arrangement?

Yes, those are still needed to accommodate pre-canned video, bitmaps, etc

[cabanier]

/agenda What should we replace the stereo layout with?

[Manishearth]

Yes, those are still needed to accommodate pre-canned video, bitmaps, etc

Should this not just use the XRMediaBinding stuff?

Even if we decide to have such layers, it still feels weird to then patch mono support in for these layers.

Overall these two seem to b pretty specal-case-y and I'm wary of adding something like that.

[cabanier]

Yes, those are still needed to accommodate pre-canned video, bitmaps, etc

Should this not just use the XRMediaBinding stuff?

No because authors will want to add other effects on top of video or use the stereo bitmaps.

Even if we decide to have such layers, it still feels weird to then patch mono support in for these layers.

Overall these two seem to b pretty specal-case-y and I'm wary of adding something like that.

I'm not adding side-by-side layout in the PR. That was already discussed in previous issues.

[Manishearth]

I'm not adding side-by-side layout in the PR. That was already discussed in previous issues.

Yes, but you are deciding a behavior for side-by-side layout textures in mono sessions, which is what's weird here.

And yeah I think this is a wider discussion that needs to be had: it was kinda ongoing in #114 but that was closed with a specific fix. I'll open something new.

[cabanier]

I'm not adding side-by-side layout in the PR. That was already discussed in previous issues.

Yes, but you are deciding a behavior for side-by-side layout textures in mono sessions, which is what's weird here.

If you have other behavior in mind, we can discuss that here.
Side-by-side layout should not break workflows that happen to be monoscopic.

[Manishearth]

Side-by-side layout should not break workflows that happen to be monoscopic.

Hmm. It still feels weird, but I won't block this. I'll file a separate issue for the existence of left-right and top-bottom.

[cabanier]

Side-by-side layout should not break workflows that happen to be monoscopic.

Hmm. It still feels weird, but I won't block this. I'll file a separate issue for the existence of left-right and top-bottom.

It was introduced by #46. We also discussed it in a weekly call but I don't know how to link that.

[Manishearth]

Yeah, I think there's a bit more to it than that. For example, even if we rename "stereo" there still needs to be a way to get viewports.

[Manishearth]

Hmm, looking at it it seems fine now, but we should probably add non-normative notes explaining these modes better.

[cabanier]

Hmm, looking at it it seems fine now, but we should probably add non-normative notes explaining these modes better.

@Manishearth I added a note. Do you think more information is needed?

[Manishearth]

Looks great, thanks!

[cabanier]

We discussed this change a bit in this week's call but we didn't resolve what name we should use.
I'm leaning towards default

Also, @toji I was wrong when I said a projection layers can be mono on a stereo device. It's defined to be always stereo (aka default) so it has the same number of subimages as the session.

[cabanier]

@toji any comments on my latest changes?

[toji]

LGTM!