Skip to content

Replace winit with raw-window-handle in backend crates #2967

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

Closed
wants to merge 10 commits into from
Closed

Replace winit with raw-window-handle in backend crates #2967

wants to merge 10 commits into from

Conversation

jamsch0
Copy link
Contributor

@jamsch0 jamsch0 commented Aug 20, 2019

Closes #2956
PR checklist:

  • make succeeds (on *nix)
  • make reftests succeeds
  • tested examples with the following backends: dx11, dx12, vulkan, wgl
  • rustfmt run on changed code

Currently Android is not supported in raw-window-handle and therefore unimplemented in gfx-backend-vulkan - waiting on rust-windowing/raw-window-handle#12 to be resolved.

Copy link
Member

@kvark kvark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, amazing work!
Aside from the comments on the review, I wonder how we should go about publishing these changes.
Several choices are available:

  1. in "hal-0.3" branch, add support for raw-window-handle in addition to winit, so that it's not breaking and users can test it out
  2. back-port this change directly to "hal-0.3" but also keep a dummy "winit" feature that changes nothing: users who had "winit" enabled and used to pass "winit::Window" would still have that code working, right? Unless they were using "winit" version that didn't have "raw-window-handle" integration itself, yet, hmm
  3. wait for "hal-0.4" release, potentially making it sooner rather than later

) -> Surface {
let hwnd = match has_handle.raw_window_handle() {
raw_window_handle::RawWindowHandle::Windows(handle) => handle.hwnd,
_ => unreachable!(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think cases like this should be panic!, because they will easily be reachable once the enum gets new variants

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes of course, I hadn't considered that. Do you have any suggestions for the error message(s)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It actually sounds like we need an error code returned for that mismatch?..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It actually sounds like we need an error code returned for that mismatch?..

Could you explain that a bit further, please?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just adding something like struct InitError in window.rs module, so that all create_surface_from_raw calls would return Result<Surface, window::InitError> instead of panicking.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought that was what you were implying, just wanted to double check :)


let hwnd = window.hwnd();
self.create_surface_from_hwnd(hwnd as *mut _)
#[cfg(windows)]
Copy link
Contributor Author

@jamsch0 jamsch0 Aug 20, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not quite sure about this, or if the entire wgl feature should be cfg(target_os = windows), or whether the unreachable should instead be something like panic!("WGL is not supported for this target")?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

latter sounds good to me. @msiglreith ?

@jamsch0
Copy link
Contributor Author

jamsch0 commented Aug 20, 2019

Wrt. how to land this change, I see now that it would be a breaking change as you mention. If you wanted to go with option 1, would that be achieved by adding create_surface(&impl HasRawWindowHandle) alongside create_surface(&winit::Window), both cfg'd out as appropriate and mutually exclusive?

@kvark
Copy link
Member

kvark commented Aug 20, 2019

Wrt. how to land this change, I see now that it would be a breaking change as you mention. If you wanted to go with option 1, would that be achieved by adding create_surface(&impl HasRawWindowHandle) alongside create_surface(&winit::Window), both cfg'd out as appropriate and mutually exclusive?

I think we can make them exclusive, but only if winit takes precedence (in case of both features enabled), so that the existing code works.

Although, a simpler (and better) path would just be to just expose it under a different name. We'll break the API in the next version anyway.

@jamsch0
Copy link
Contributor Author

jamsch0 commented Aug 20, 2019

Although, a simpler (and better) path would just be to just expose it under a different name. We'll break the API in the next version anyway.

Ok, in that case I'll go ahead and do that, maybe with the name create_surface_from_raw for now? (Obviously feel free to bikeshed.)

@kvark
Copy link
Member

kvark commented Aug 20, 2019

Although, a simpler (and better) path would just be to just expose it under a different name. We'll break the API in the next version anyway.

Ok, in that case I'll go ahead and do that, maybe with the name create_surface_from_raw for now? (Obviously feel free to bikeshed.)

Sounds great, thank you!

(to clarify, this would need to be done in a separate PR targeting hal-0.3 branch and bumping the patch versions)

@jamsch0
Copy link
Contributor Author

jamsch0 commented Aug 20, 2019

I've now opened #2968 with these changes as additive against the hal-0.3 branch. Will address your remaining feedback there.

@jamsch0 jamsch0 closed this Aug 20, 2019
@kvark
Copy link
Member

kvark commented Aug 20, 2019

@jchapman127 would you mind landing this PR though? We still want this very change in master.

@kvark kvark reopened this Aug 20, 2019
@jamsch0
Copy link
Contributor Author

jamsch0 commented Aug 20, 2019

@jchapman127 would you mind landing this PR though? We still want this very change in master.

Does that include changing create_surface to return Result<InitError>?

@kvark
Copy link
Member

kvark commented Aug 20, 2019

@jchapman127 would you mind landing this PR though? We still want this very change in master.

Does that include changing create_surface to return Result<InitError>?

That would be great, yeah! Especially, since you've done this for hal-0.3 already, so it shouldn't be difficult to port back here.

bors bot added a commit that referenced this pull request Aug 21, 2019
2968: [hal-0.3] Add support for `raw-window-handle` r=kvark a=jchapman127

Fixes #2956.
Closes #2967.
PR checklist:
- [ ] `make` succeeds (on *nix)
- [ ] `make reftests` succeeds
- [ ] tested examples with the following backends:
- [x] `rustfmt` run on changed code

Non-breaking change version of #2967.

Currently Android is not supported in raw-window-handle and therefore unimplemented in gfx-backend-vulkan - waiting on rust-windowing/raw-window-handle#12 to be resolved.

Co-authored-by: James Chapman <[email protected]>
bors bot added a commit that referenced this pull request Aug 21, 2019
2968: [hal-0.3] Add support for `raw-window-handle` r=kvark a=jchapman127

Fixes #2956.
Closes #2967.
PR checklist:
- [ ] `make` succeeds (on *nix)
- [ ] `make reftests` succeeds
- [ ] tested examples with the following backends:
- [x] `rustfmt` run on changed code

Non-breaking change version of #2967.

Currently Android is not supported in raw-window-handle and therefore unimplemented in gfx-backend-vulkan - waiting on rust-windowing/raw-window-handle#12 to be resolved.

Co-authored-by: James Chapman <[email protected]>
bors bot added a commit that referenced this pull request Aug 23, 2019
2968: [hal-0.3] Add support for `raw-window-handle` r=kvark a=jchapman127

Closes #2956.
PR checklist:
- [x] `make` succeeds (on *nix)
- [x] `make reftests` succeeds
- [ ] tested examples with the following backends:
- [x] `rustfmt` run on changed code

Non-breaking change version of #2967.

Currently Android is not supported in raw-window-handle and therefore unimplemented in gfx-backend-vulkan - waiting on rust-windowing/raw-window-handle#12 to be resolved.

Co-authored-by: James Chapman <[email protected]>
@bors bors bot closed this in fb76260 Oct 9, 2019
@bors bors bot closed this in #3038 Oct 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Please add support for the new raw-window-handle crate
2 participants