Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Requirements for native viewport size? #777

Closed
asajeffrey opened this issue Jul 24, 2019 · 2 comments · Fixed by #976
Closed

Requirements for native viewport size? #777

asajeffrey opened this issue Jul 24, 2019 · 2 comments · Fixed by #976
Labels
fixed by pending PR A PR that is in review will resolve this issue. help wanted This is a good issue for anyone to pick up and work on filing a PR for.
Milestone

Comments

@asajeffrey
Copy link

Over in immersive-web/webxr-test-api#37 there is a discussion about whether WebXR tests can assert anything about viewport sizes. The motivation for this is to make sure that the dimensions being reported are based on the device, not based on the canvas providing the WebGL rendering context. (This was a bug that Servo had, so we'd like to make sure we don't regress.) In immersive-web/webxr-test-api#37 (comment), @alcooper91 said "I’m unable to find anything in the WebXR spec calling out any requirements for sizing the canvas/viewport, so the output size is largely up to the UAs."

This is true, there is text at https://immersive-web.github.io/webxr/#native-webgl-framebuffer-resolution about the native viewport resolution, but there is no text about a native viewport size. https://immersive-web.github.io/webxr/#list-of-viewports requires that the XRSession keep a list of viewports, but nothing about the size of the viewports.

Can we add matching requirements for viewport size?

@toji
Copy link
Member

toji commented Nov 5, 2019

It's slightly difficult to put much in the way of meaningful requirements in place here that don't feel arbitrary. I think it should be non-controversial to say that is must be a valid viewport in that the viewport must be at least 1x1 in size, and the coordinate must all lie within the framebuffer. There's already a documented requirement in the spec that they be non-overlapping. Beyond that I'm not sure, as we do want to allow plenty of UA/platform-specific behavior here. (Some devices change the viewports every frame, for example.)

There's definitely some common sense behavior you'd expect from the viewports but are hard to justify putting into the spec text. Most of us would recognize an 8x1024 viewport as absurd for this kind of use, but I could also probably invent some silly potential uses such a thing given an overabundance of spare time, so it's really just a question of what limitations we'd actually benefit from.

@Manishearth Manishearth modified the milestones: November 2019, Pre-CR Dec 2, 2019
@Manishearth Manishearth added the help wanted This is a good issue for anyone to pick up and work on filing a PR for. label Dec 2, 2019
@probot-label
Copy link

probot-label bot commented Mar 4, 2020

This issue is fixed by PR #976

@probot-label probot-label bot added the fixed by pending PR A PR that is in review will resolve this issue. label Mar 4, 2020
@toji toji closed this as completed in #976 Mar 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fixed by pending PR A PR that is in review will resolve this issue. help wanted This is a good issue for anyone to pick up and work on filing a PR for.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants