Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd support for XRInputSource and target ray spaces #23292
Conversation
highfive
commented
Apr 30, 2019
|
Heads up! This PR modifies the following files:
|
highfive
commented
Apr 30, 2019
|
I'm getting a link error when compiling for android, but it bisects down to ee0bb1c , which makes no sense since that PR just introduces a new interface |
|
The link error is:
|
|
This works! I've got a test program at https://manishearth.net/sand/webgl-to-webvr/webxr-input.html. It doesn't show a ray but the triangle tracks the input device pretty well. |
|
r? @jdm or @asajeffrey |
|
Mostly looks good, my only real worry is that by making the gamepad state synchronous we'll end up introducing the same deadlock as for frames (which is why frames are async). |
| #[derive(Deserialize, Serialize)] | ||
| pub struct WebVRPoseInformation { | ||
| pub frame: WebVRFutureFrameData, | ||
| pub gamepads: Vec<(u32, WebVRGamepadState)>, |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
asajeffrey
May 6, 2019
Member
The frame is a asynchronous, but the gamepad state is synchronous, which seems odd, at least worth commenting on. IIRC the frame is async to deal with the case that the frame data is only available on the main thread, to avoid having the webgl thread block on the main thread, since that can cause deadlock. Are there platforms where the gamepad state is also only available on the main thread?
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
asajeffrey
May 6, 2019
Member
I think the magicleap assumes that gamepad state is queried on the main thread, but I'm not sure if this is a requirement, or just the way their example code is written.
| gamepads: vec![], | ||
| }; | ||
| if get_gamepads { | ||
| let gamepads = unsafe { (*compositor.0).fetch_gamepads() }; |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Manishearth
May 6, 2019
Author
Member
Depends on the device impl, I guess, right now I don't think it does for googlevr.
| }) | ||
| .collect(); | ||
| sender.send(Ok(data)).unwrap(); | ||
| }, |
This comment has been minimized.
This comment has been minimized.
asajeffrey
May 6, 2019
Member
Nit: can we not use the impl of collect() for iterators where Item=Result<T,E> to simplify this?
This comment has been minimized.
This comment has been minimized.
Manishearth
May 6, 2019
Author
Member
Item isn't a result here, the entire list is. We could simplify this a bit with a .map, maybe
| @@ -30,3 +30,9 @@ pub use rust_webvr_api::VRLayer as WebVRLayer; | |||
| pub use rust_webvr_api::VRMainThreadHeartbeat as WebVRMainThreadHeartbeat; | |||
| pub use rust_webvr_api::VRPose as WebVRPose; | |||
| pub use rust_webvr_api::VRStageParameters as WebVRStageParameters; | |||
|
|
|||
| #[derive(Deserialize, Serialize)] | |||
| pub struct WebVRPoseInformation { | |||
This comment has been minimized.
This comment has been minimized.
asajeffrey
May 6, 2019
Member
bikeshed: not sure PoseInformation is the best name for data about the frame + gamepad state.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Addressed. I haven't made the gamepad stuff async, perhaps that can be a followup? |
|
OK, as long as we follow up on it. Tracking down deadlocks is not fun! |
|
@bors-servo r=asajeffrey |
Add support for XRInputSource and target ray spaces Untested, but compiles. r? @jdm or @asajeffrey <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23292) <!-- Reviewable:end -->
|
|
|
|
@bors-servo retry |
Add support for XRInputSource and target ray spaces Untested, but compiles. r? @jdm or @asajeffrey <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23292) <!-- Reviewable:end -->
|
|
|
@bors-servo retry |
|
Doesn't need p=1 anymore since the build results are long gone @bors-servo p=0 |
Add support for XRInputSource and target ray spaces Untested, but compiles. r? @jdm or @asajeffrey <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23292) <!-- Reviewable:end -->
|
|
@Manishearth I am getting this link error locally. Did you manage to fix it? |
|
Switching to normal It's not our bug, it's caused by hitting a threshold of binary size on the linker, it seems. When I was bisecting this it bisected to a commit that added a blank interface, and the bisection kept changing as I rebased. |
Manishearth commentedApr 30, 2019
•
edited by SimonSapin
Untested, but compiles.
r? @jdm or @asajeffrey
This change is