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

Implement access of raw context handles #939

Merged
merged 5 commits into from
Oct 5, 2017
Merged

Implement access of raw context handles #939

merged 5 commits into from
Oct 5, 2017

Conversation

ebkalderon
Copy link
Contributor

@ebkalderon ebkalderon commented Oct 3, 2017

Added

Fixed

  • Minor formatting changes, i.e. fixing some spacing, reordering imports, etc.
  • Fix small doc comment typo.

CC @tomaka @kvark

@ebkalderon ebkalderon changed the title Implement GlContextExt for getting raw context handles Implement access of raw context handles Oct 3, 2017
@tomaka
Copy link
Contributor

tomaka commented Oct 4, 2017

Thanks for the PR.

I haven't read the PR in details yet, but I have three remarks:

  • I don't think the method should be named as_mut_ptr, because that supposes that it returns a pointer.
  • I'd prefer if the code in the platform module didn't import anything from the os module. The retrieval methods should be directly implemented on the context, and not through a trait.
  • The GlContext trait implementations shouldn't use types that aren't integers or void pointers. I don't know if it's the case right now in your PR, but for example returning an opaque object or a pointer to an opaque object wouldn't be good.

@ebkalderon
Copy link
Contributor Author

I appreciate the helpful feedback!

  1. Sounds good. Perhaps raw_handle() or raw() or some similar permutation be a better name? Or do you have another preference in mind?
  2. Will do. Shall I implement GlContextExt directly on the top-level glutin::Context instead?
  3. I've already made sure of that, but please double-check in case of mistakes.

@tomaka
Copy link
Contributor

tomaka commented Oct 4, 2017

Sounds good. Perhaps raw_handle() or raw() or some similar permutation be a better name?

I'd say raw_handle looks good.

Will do. Shall I implement GlContextExt directly on the top-level glutin::Context instead?

The GlContextExt trait shouldn't be used or mentionned anywhere, except in the files of the os module. In other words it should be totally isolated in this module.

It's not necessarily a hard-written rule, but that's how all other traits of os work right now, and it's better when everything uses the same design.

@ebkalderon
Copy link
Contributor Author

The GlContextExt trait shouldn't be used or mentionned anywhere, except in the files of the os module. In other words it should be totally isolated in this module.

I believe you might have misunderstood my original question, but thanks for the helpful guideline. I was asking whether I should implement GlContextExt for glutin::Context in the same manner that WindowExt is implemented for winit::Window (relevant source).

@tomaka
Copy link
Contributor

tomaka commented Oct 4, 2017

I believe you might have misunderstood my original question, but thanks for the helpful guideline. I was asking whether I should implement GlContextExt for glutin::Context in the same manner that WindowExt is implemented for winit::Window (relevant source).

Well, the answer is yes. Just move the impl ... for ... to the various submodules of os.
I'm confused by your question because implementing GlContextExt on Context is the whole point of the PR!

@ebkalderon
Copy link
Contributor Author

ebkalderon commented Oct 4, 2017

Sorry if I wasn't being clear then, haha. I meant implementing for glutin::Context in contrast to implementing it against the platform::Contexts. Give me a break, I have been running very low on coffee these past few days! 😂

@@ -186,6 +190,11 @@ impl OsMesaContext {
pub fn get_pixel_format(&self) -> PixelFormat {
unimplemented!();
}

#[inline]
pub unsafe fn raw_handle(&self) -> osmesa_sys::OSMesaContext {
Copy link
Contributor

Choose a reason for hiding this comment

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

That's not a void pointer.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Isn't OSMesaContext a mutable pointer to an opaque struct meant to be used identically to *mut c_void?

Copy link
Contributor

Choose a reason for hiding this comment

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

They are equivalent, but using a c_void makes it more semver-friendly. Sorry for not going into details.
You should return a *mut c_void and cast the OSMesaContext to it with as.

Copy link
Contributor Author

@ebkalderon ebkalderon Oct 4, 2017

Choose a reason for hiding this comment

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

Okay, will do.

EDIT: Should I use a *mut libc::c_void or a *mut std::os::raw::c_void? The two types aren't compatible with each other, unfortunately. See rust-lang/libc#180. I'm assuming the former, since you have libc as a dependency.

Copy link
Contributor

Choose a reason for hiding this comment

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

No, please use the std::os::raw one.
The libc dependency should be removed eventually, but since doing so requires a major version bump, I never think about doing it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Got it, std::os::raw it is!

@@ -198,6 +197,11 @@ impl Context {
pub fn get_pixel_format(&self) -> PixelFormat {
self.pixel_format.clone()
}

#[inline]
pub unsafe fn raw_handle(&self) -> winapi::HDC {
Copy link
Contributor

Choose a reason for hiding this comment

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

Not a void pointer.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch! Thank you, I should have made it into an HGLRC instead.

src/os/macos.rs Outdated
use os::GlContextExt;

impl GlContextExt for Context {
type Handle = id;
Copy link
Contributor

Choose a reason for hiding this comment

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

Not a void pointer.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What type should I use instead? I am not too familiar with OpenGL on Mac OS X.

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Gotcha. Same rules as with OSMesaContext, then.

@tomaka
Copy link
Contributor

tomaka commented Oct 5, 2017

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Getting raw pointer to platform GL context
2 participants