Allow caching various objects (take 2) #1088
Conversation
index.bs
Outdated
| 1. Let |viewport| be a [=new=] {{XRViewport}} in the [=relevant realm=] of |layer|'s [=XRWebGLLayer/session=]. | ||
| 1. Initialize |viewport| as follows: | ||
| <dl class="switch"> | ||
| <dt>If a |view| with the same underlying [=view=] has been passed to a getViewport() call previously, and |glViewport| has not changed since then, the user agent MAY:</dt> |
There was a problem hiding this comment.
This MAY can probably safely be a MUST
index.bs
Outdated
| 1. Let |viewport| be a [=new=] {{XRViewport}} in the [=relevant realm=] of |layer|'s [=XRWebGLLayer/session=]. | ||
| 1. Initialize |viewport| as follows: | ||
| <dl class="switch"> | ||
| <dt>If a |view| with the same underlying [=view=] has been passed to a getViewport() call previously, and |glViewport| has not changed since then, the user agent MAY:</dt> |
There was a problem hiding this comment.
| <dt>If a |view| with the same underlying [=view=] has been passed to a getViewport() call previously, and |glViewport| has not changed since then, the user agent MAY:</dt> | |
| <dt>If a |view| with the same underlying [=view=] has been passed to this |layer|'s getViewport() call previously, the user agent MAY:</dt> |
Is "with the same underlying [=view=]" needed?
There was a problem hiding this comment.
Probably, since XRViews aren't a good candidate for caching. (The transform and projectionMatrix make them closer to a POD structure like XRPose than an opaque key, though I made that same mistake in the previous PR)
There was a problem hiding this comment.
@cabanier yes, you have a different XRView object each frame
index.bs
Outdated
| 1. Let |frame| be a [=new=] {{XRFrame}} with [=XRFrame/time=] |frameTime| and {{XRFrame/session}} |session| in the [=relevant realm=] of |session|. | ||
| 1. Initialize |frame| as follows: | ||
| <dl class="switch"> | ||
| <dt>If |session| has previously run an [=XR animation frame=], the user agent MAY:</dt> |
There was a problem hiding this comment.
This MAY could be a MUST, which would prevent content that stashes stuff on frames from behaving differently on different browsers (though content shouldn't really be relying on that anyway).
But we should definitely check with UAs before doing this
|
/agenda To discuss how people feel about unconditionally caching, and whether there's anything that can be done about poses |
|
In the call Rik pointed out that DOM uses a "may" for this in |
|
Maybe we need to get input from the TAG on this, especially if we're the first spec to mandate the return of the same object. |
|
@cabanier I don't think that's anything special, e.g. both things can be better specified by caching the frame and viewports on the session. But I'm open to using a MAY here either way. |
|
I prefer a MAY. |
|
I've updated the text to use MUST after discussing with Brandon. There's a nicer way to spec this so that we're not really mandating "the same object", but that's a purely editorial thing that I'm going to file a followup about. |
|
Opened #1090 to improve the text and make the caching more explicit |
Fixes #1010
Second attempt at #1086
This PR only caches:
We determined that caching poses is probably too dangerous since they're "plain old data" types that folks may choose to hold on to. Leaving #1086 as a separate PR if people are interested in seeing how that would work.
cc @asajeffrey @MortimerGoro @cabanier
Preview | Diff