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

raw-window-handle support #229

Open
LordBenjamin opened this issue Sep 7, 2019 · 4 comments
Open

raw-window-handle support #229

LordBenjamin opened this issue Sep 7, 2019 · 4 comments

Comments

@LordBenjamin
Copy link

Apologies if this is covered by an existing issue (perhaps #129 or #161?) but is there any plan to support raw-window-handle? Or otherwise easily initialize three to render to an existing window?

@LordBenjamin
Copy link
Author

The glutin::EventsLoop type is used in both src/window.rs (created as a precursor to creating a window) and src/render/mod.rs (passed to gfx_window_glutin::init(), which in itself is a wrapper for glutin::Window).

If we're receiving a handle to an external window via raw-window-handle, we won't own the event loop and might not even be able to get a reference to it (especially if the window wasn't built by glutin)

It's probably OK in window.rs since this isn't necessary to run three (as I understand it, one could construct a Renderer, Factory, etc without a Window?) and provides a default windowing implementation for ease of use.

Am I right in thinking the actions here would be:

  • Decouple Renderer from event loop dependency
  • Decouple Renderer from glutin dependency
  • Replace gfx_window_glutin::* function calls with raw-window-handle equivalents
  • Replace usage of glutin::GlWindow with raw-window-handle equivalent (outside of window.rs)
  • Replace usage of glutin::dpi::LogicalSize with a generic equivalent (outside of window.rs)

Could possibly be done by making these conditional on a glutin feature and then fixing compile errors?

@LordBenjamin
Copy link
Author

Possibly makes sense to wait for #230 to merge before making changes that might conflict?

@kvark
Copy link
Collaborator

kvark commented Sep 9, 2019

Glutin dependency is fairly tightly integrated right now, as you found out. One of the driving principles behind this project is to have a pure-rust tech stack. In this sense, glutin is the only way forward, hence there was no strong force to decouple it. Saying that, making the code more structured and relying on RawWindowHandle at the crate boundaries would still be a win.

@LordBenjamin
Copy link
Author

Had a look tonight since #230 has been merged.

Am I right in thinking that for the Renderer::new() to accept a RawWindowHandle (i.e. minimum change to provide RawWindowHandle at the crate boundary), we'll need to change the glutin context from WindowedContext to RawContext?

If so, this might require a gfx change since gfx_window_glutin::init() expects a WindowedContext.

The main reason for gfx requiring WindowedContext instead of ContextWrapper seems to be that gfx needs to be able to determine the size of the window (https://github.com/gfx-rs/gfx/blob/4d8a4221a47ef68077eb6fcff438a659dc973283/src/window/glutin/src/lib.rs#L106). I can't see a way of determining the size of a window from a RawContext.

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

No branches or pull requests

2 participants