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

Port glutin to winit #813

Closed
ozkriff opened this Issue Sep 14, 2016 · 20 comments

Comments

Projects
None yet
7 participants
@ozkriff
Collaborator

ozkriff commented Sep 14, 2016

In #726 (comment) you said:

The situation it's that it's painful but not difficult to switch glutin to winit and I don't have time and motivation to do that.

The situation/plans have not changed? I would like to try to help with this if you don't mind :)

@kvark

This comment has been minimized.

Show comment
Hide comment
@kvark

kvark Sep 14, 2016

Contributor

GFX and Amethyst would very much benefit from this long-awaited change! cc @ebkalderon

Contributor

kvark commented Sep 14, 2016

GFX and Amethyst would very much benefit from this long-awaited change! cc @ebkalderon

@ebkalderon

This comment has been minimized.

Show comment
Hide comment
@ebkalderon

ebkalderon Sep 14, 2016

Contributor

I agree with @kvark, having a windowing framework that isn't tied to any particular graphics API would be terrific!

Contributor

ebkalderon commented Sep 14, 2016

I agree with @kvark, having a windowing framework that isn't tied to any particular graphics API would be terrific!

@tomaka

This comment has been minimized.

Show comment
Hide comment
@tomaka

tomaka Sep 14, 2016

Owner

The things to do are basically:

  • Merge glutin master in winit master. The git history is the same, but there have been PRs submitted to glutin after the fork and that haven't been merged.
  • Add pub use statements in main.rs to reexport all the types that are in winit (ie. everything related to windowing).
  • Remove win32 and x11 from src/api.
  • Modify android in src/api so that it just creates an OpenGL context over a window passed by parameter (the changes are probably very small).
  • Modify wayland in src/api so that it just creates an OpenGL context over a window passed by parameter (the changes are probably a bit special since wayland's architecture is weird).
  • Modify cocoa in src/api so that it just creates an OpenGL context over a window passed by parameter, instead of creating the window itself.
  • Modify the files in src/platform/* (the content of these files are the layer right under the public API) to create a window from winit and an OpenGL context from one of the modules in src/api.

The amount of work is probably very large for just one person though.

Owner

tomaka commented Sep 14, 2016

The things to do are basically:

  • Merge glutin master in winit master. The git history is the same, but there have been PRs submitted to glutin after the fork and that haven't been merged.
  • Add pub use statements in main.rs to reexport all the types that are in winit (ie. everything related to windowing).
  • Remove win32 and x11 from src/api.
  • Modify android in src/api so that it just creates an OpenGL context over a window passed by parameter (the changes are probably very small).
  • Modify wayland in src/api so that it just creates an OpenGL context over a window passed by parameter (the changes are probably a bit special since wayland's architecture is weird).
  • Modify cocoa in src/api so that it just creates an OpenGL context over a window passed by parameter, instead of creating the window itself.
  • Modify the files in src/platform/* (the content of these files are the layer right under the public API) to create a window from winit and an OpenGL context from one of the modules in src/api.

The amount of work is probably very large for just one person though.

@kvark

This comment has been minimized.

Show comment
Hide comment
@kvark

kvark Sep 14, 2016

Contributor

Thanks @tomaka ! This is a very nice task breakdown and the plan to follow.

Contributor

kvark commented Sep 14, 2016

Thanks @tomaka ! This is a very nice task breakdown and the plan to follow.

@ozkriff

This comment has been minimized.

Show comment
Hide comment
@ozkriff

ozkriff Oct 7, 2016

Collaborator

Slowly working on draft for this in https://github.com/ozkriff/glutin/tree/omg branch.

Draft for linux/x11 works.

@Vinatorul is working on wayland backend.

Collaborator

ozkriff commented Oct 7, 2016

Slowly working on draft for this in https://github.com/ozkriff/glutin/tree/omg branch.

Draft for linux/x11 works.

@Vinatorul is working on wayland backend.

@tomaka

This comment has been minimized.

Show comment
Hide comment
@tomaka

tomaka Oct 7, 2016

Owner

@ozkriff I'd like to highlight that:

Add pub use statements in main.rs to reexport all the types that are in winit (ie. everything related to windowing).

The glutin user shouldn't have to add winit to their Cargo.toml in order to use glutin.

Owner

tomaka commented Oct 7, 2016

@ozkriff I'd like to highlight that:

Add pub use statements in main.rs to reexport all the types that are in winit (ie. everything related to windowing).

The glutin user shouldn't have to add winit to their Cargo.toml in order to use glutin.

@vberger

This comment has been minimized.

Show comment
Hide comment
@vberger

vberger Oct 7, 2016

Collaborator

@ozkriff @Vinatorul Don't try too hard with the wayland backend, as said in an other issue, I'm going to completely rewrite the winit wayland backend following my complete redesign of tha wayland-client API with version 0.7, which will likely slightly change the wayland-EGL plumbing API (to make it more safe)

Collaborator

vberger commented Oct 7, 2016

@ozkriff @Vinatorul Don't try too hard with the wayland backend, as said in an other issue, I'm going to completely rewrite the winit wayland backend following my complete redesign of tha wayland-client API with version 0.7, which will likely slightly change the wayland-EGL plumbing API (to make it more safe)

@tomaka

This comment has been minimized.

Show comment
Hide comment
@tomaka

tomaka Oct 7, 2016

Owner

@vberger There's a high chance that they finish the rework before you.

Owner

tomaka commented Oct 7, 2016

@vberger There's a high chance that they finish the rework before you.

@ozkriff

This comment has been minimized.

Show comment
Hide comment
@ozkriff

ozkriff Oct 7, 2016

Collaborator

The glutin user shouldn't have to add winit to their Cargo.toml in order to use glutin.

@tomaka Right now zoc works on linux/x11 without any changes if I add my forked glutin to .cargo/config :) .

By the way, what is the future of ios and emscripten backends? You haven't mentioned them in plan.

Collaborator

ozkriff commented Oct 7, 2016

The glutin user shouldn't have to add winit to their Cargo.toml in order to use glutin.

@tomaka Right now zoc works on linux/x11 without any changes if I add my forked glutin to .cargo/config :) .

By the way, what is the future of ios and emscripten backends? You haven't mentioned them in plan.

@tomaka

This comment has been minimized.

Show comment
Hide comment
@tomaka

tomaka Oct 7, 2016

Owner

The emscripten can should stay as it is now, as there's no advantage in moving it to winit.
For iOS the problem is that we don't have anybody to test the changes, as it's a bit hacky to setup (iOS is missing an equivalent to cargo-apk). It's probably fine to leave it and add a "TODO: use winit as a backend".

If you add methods to convert between glutin and winit, just put unimplemented!() for these two targets.

Owner

tomaka commented Oct 7, 2016

The emscripten can should stay as it is now, as there's no advantage in moving it to winit.
For iOS the problem is that we don't have anybody to test the changes, as it's a bit hacky to setup (iOS is missing an equivalent to cargo-apk). It's probably fine to leave it and add a "TODO: use winit as a backend".

If you add methods to convert between glutin and winit, just put unimplemented!() for these two targets.

@vberger

This comment has been minimized.

Show comment
Hide comment
@vberger

vberger Oct 7, 2016

Collaborator

Just to be more clear: with my previous message I didn't mean to consider my of the internals as blocking you. But if you reach a point where things get too messy with wayland on the old wayland-client API, just leave it as unimplemented!() and I'll correct it with the new backend afterwards.

Collaborator

vberger commented Oct 7, 2016

Just to be more clear: with my previous message I didn't mean to consider my of the internals as blocking you. But if you reach a point where things get too messy with wayland on the old wayland-client API, just leave it as unimplemented!() and I'll correct it with the new backend afterwards.

@Vinatorul

This comment has been minimized.

Show comment
Hide comment
@Vinatorul

Vinatorul Oct 7, 2016

Contributor

@vberger I have one idea how to do it without hacks after conversation in winit issue. If it won't work - then I'll just wait for new API.

Contributor

Vinatorul commented Oct 7, 2016

@vberger I have one idea how to do it without hacks after conversation in winit issue. If it won't work - then I'll just wait for new API.

@ozkriff

This comment has been minimized.

Show comment
Hide comment
@ozkriff

ozkriff Oct 9, 2016

Collaborator

Android backend works. Moving to work on windows backend.

Collaborator

ozkriff commented Oct 9, 2016

Android backend works. Moving to work on windows backend.

@ozkriff

This comment has been minimized.

Show comment
Hide comment
@ozkriff

ozkriff Oct 15, 2016

Collaborator

cargo run --example window works on windows. Started polishing code + trying to fix headless mode.

Collaborator

ozkriff commented Oct 15, 2016

cargo run --example window works on windows. Started polishing code + trying to fix headless mode.

@sumproxy

This comment has been minimized.

Show comment
Hide comment
@sumproxy

sumproxy Oct 17, 2016

Contributor

macOS backend now works in a draft version too. @ozkriff will test the commits against other platforms to see if the changes are valid.

Contributor

sumproxy commented Oct 17, 2016

macOS backend now works in a draft version too. @ozkriff will test the commits against other platforms to see if the changes are valid.

@ozkriff

This comment has been minimized.

Show comment
Hide comment
@ozkriff

ozkriff Oct 18, 2016

Collaborator

@tomaka I have a problem with Headless mode on win32:

I don't know how to get rid of winit::Window here:

https://github.com/ozkriff/glutin/blob/6ecf9e5/src/platform/windows/mod.rs#L136

because I need winapi::HWND from it for context creation here:

https://github.com/ozkriff/glutin/blob/6ecf9e5/src/platform/windows/mod.rs#L136

Collaborator

ozkriff commented Oct 18, 2016

@tomaka I have a problem with Headless mode on win32:

I don't know how to get rid of winit::Window here:

https://github.com/ozkriff/glutin/blob/6ecf9e5/src/platform/windows/mod.rs#L136

because I need winapi::HWND from it for context creation here:

https://github.com/ozkriff/glutin/blob/6ecf9e5/src/platform/windows/mod.rs#L136

@tomaka

This comment has been minimized.

Show comment
Hide comment
@tomaka

tomaka Oct 18, 2016

Owner

@ozkriff Well, you need to create a window yourself at this location.

Owner

tomaka commented Oct 18, 2016

@ozkriff Well, you need to create a window yourself at this location.

@ozkriff

This comment has been minimized.

Show comment
Hide comment
@ozkriff

ozkriff Oct 18, 2016

Collaborator

Ok, seems like the only solution :( .

And, by the way, what should I do with WindowAttributes and PlatformSpecificWindowBuilderAttributes in glutin?

  • Duplicate all winit::WindowBuilder::with_* functions in glutin::WindowBuilder? (convenient for user but might become a support nightmare)
  • Let the user user create winit::WIndow himself and pass it to glutin::WindowBuilder::with_window or create default wint::Window? (DRY, but forces most of the users to use winit)
Collaborator

ozkriff commented Oct 18, 2016

Ok, seems like the only solution :( .

And, by the way, what should I do with WindowAttributes and PlatformSpecificWindowBuilderAttributes in glutin?

  • Duplicate all winit::WindowBuilder::with_* functions in glutin::WindowBuilder? (convenient for user but might become a support nightmare)
  • Let the user user create winit::WIndow himself and pass it to glutin::WindowBuilder::with_window or create default wint::Window? (DRY, but forces most of the users to use winit)
@tomaka

This comment has been minimized.

Show comment
Hide comment
@tomaka

tomaka Oct 18, 2016

Owner

Ok, seems like the only solution :( .

It's the solution by design. Windows has nothing to create headless contexts (except an AMD-specific stuff) so we create a hidden window.

Duplicate all winit::WindowBuilder::with_* functions in glutin::WindowBuilder? (convenient for user but might become a support nightmare)

This one.
By doing so we can add our own functions (for example allowing the user to choose between EGL and GLX), plus there may be situations in the future where want to deny access to some of the winit::WindowBuilder::with_* functions.

Owner

tomaka commented Oct 18, 2016

Ok, seems like the only solution :( .

It's the solution by design. Windows has nothing to create headless contexts (except an AMD-specific stuff) so we create a hidden window.

Duplicate all winit::WindowBuilder::with_* functions in glutin::WindowBuilder? (convenient for user but might become a support nightmare)

This one.
By doing so we can add our own functions (for example allowing the user to choose between EGL and GLX), plus there may be situations in the future where want to deny access to some of the winit::WindowBuilder::with_* functions.

@ozkriff

This comment has been minimized.

Show comment
Hide comment
@ozkriff

ozkriff Nov 3, 2016

Collaborator

Done in #819

Collaborator

ozkriff commented Nov 3, 2016

Done in #819

@ozkriff ozkriff closed this Nov 3, 2016

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