Conversation
|
@AdaRoseCannon here's the long promised PR for layers :-) |
|
Thank you so much ⭐ |
|
|
||
| Creating the layer will immediately start its browser session. The session won't be released until the layer's `destroy()` method is called. | ||
|
|
||
| Hit testing is done according to the `targetRayMode` of the current session. Layers that do not have a `blendTextureSourceAlpha` will block hit testing of DOM layers. |
There was a problem hiding this comment.
Sessions don't have targetRayModes, inputs do.
Also, I think a bit more detail in needed about the behavior when a layer does have blendTextureSourceAlpha.
| <pre class="idl"> | ||
| dictionary XRDOMLayerInit { | ||
| required XRSpace space; | ||
| XRRigidTransform? transform; |
There was a problem hiding this comment.
How is the DOM content sized? The width and height in the QuadLayer are in-world and it would be difficult to infer a required pixel scale from them. Similar things apply to the other layers.
|
|
||
| <pre class="idl"> | ||
| [SecureContext, Exposed=Window] | ||
| interface XRDOMQuadLayerResult { |
There was a problem hiding this comment.
Not sure if I like this pattern, because it breaks from the other two layer sources. You can no longer use the result of the create*Layer call directly. Especially because it's feasible that some developers may pass the URL for the layer and then never interact with the layer's window contents again.
Could we instead add a getWindow() method to the XRDOMLayerBinding? Yes, it wouldn't apply to every layer, but we already have that situation with the WebGL layers and get[Sub]Image().
There was a problem hiding this comment.
+1, I'd rather do some getWindow() thing if it's really necessary
| constructor(XRSession session); | ||
|
|
||
| XRDOMQuadLayerResult createQuadLayer(DOMString url, optional XRDOMQuadLayerInit init = {}); | ||
| XRDOMCylinderLayerResult createCylinderLayer(DOMString video, optional XRDOMCylinderLayerInit init = {}); |
There was a problem hiding this comment.
| XRDOMCylinderLayerResult createCylinderLayer(DOMString video, optional XRDOMCylinderLayerInit init = {}); | |
| XRDOMCylinderLayerResult createCylinderLayer(DOMString url, optional XRDOMCylinderLayerInit init = {}); |
| <pre class="idl"> | ||
| dictionary XRDOMQuadLayerInit : XRDOMLayerInit { | ||
| float? width; | ||
| float? height; |
There was a problem hiding this comment.
Why are these nullable? My guess would be so that a default ratio can be determined from the window dimensions, in which case the windowPixel* attribs I mentioned above are all the more important.
At least a brief note describing the intent behind making these nullable would be appreciated, even if the exact logic will be fleshed out later.
| dictionary XRDOMCylinderLayerInit : XRDOMLayerInit { | ||
| float radius = 2.0; | ||
| float centralAngle = 0.78539; | ||
| float? aspectRatio; |
There was a problem hiding this comment.
Ditto for mentioning why this is nullable.
There was a problem hiding this comment.
though I assume we'll get this when the algorithm is filled in.
| - The URL has to be same origin as the your session | ||
| - The layer is not allowed to navigate to a different origin | ||
| - The layer is not allowed to create nested context (ie no \<iframe>) | ||
|
|
There was a problem hiding this comment.
Not sure whether the security needs to be more restrictive than an iframe. One would like to be able to show external content, when it is allowed by the origin and external source, like in this mockup SpaceX control room
For same origin content I think one should be able to use the events in DOM to react in the 3d environment, like here Virtual shop
|
Any interest in picking this back up? DOM layers would be very useful to help fulfill usecases similar to what https://hyperbeam.com/ provides, but in a spatial context. |
|
There is interest but every time we discuss the proposal, we come up with more security problems that require workarounds. :-( |
6 participants
Preview | Diff