OpenGL support

[Lokathor]

Just a note here that OpenGL requires additional info than just the window pointer for proper context creation, so we'll have to be sure to add that as a cargo feature (off by default).

[Ralith]

Why does it need to be a feature?

[Lokathor]

Honestly... I forget.

I wrote this down right after the meeting last week because, I think it was @Osspial who said that extra info was needed for GL but not all the time.

Or perhaps it was @kvark who said that gfx-backend-gl needed the extra info of some sort to fully disconnect from directly interacting with winit/glutin.

[kvark]

Yes, I was the one. OpenGL can't work off a platform-independent window (like other APIs), because the ways to create OpenGL context on many platforms are tightly integrated with window creation. So if you have a window, and it doesn't happen to have a GL context established, there is no way to build one based on the window. Therefore, this crate can have a bit of API exposing raw GL contexts in addition to the windows.

[Osspial]

Is this necessary, actually? I've done a significant amount of OpenGL programming, and as long as the OpenGL context is active and there's a way for the OpenGL wrapper to get handles to the proper function pointers you can render to OpenGL just fine.

[kvark]

@Osspial right, so if GL context is created and active, and nothing touches it or tries to access it from different threads, we are good. What if there are 2 windows? The user of raw-window-handle would then become responsible for managing the GL contexts. I.e. the user passes the window handle to a library, and suddenly they need to know precisely where and when the library is going to need that active GL context...

[Didgy74]

I think it would be fine if you just exposed a trait that did stuff like create_context, make_context_active, swap_gl_buffers.

[Osspial]

@kvark that... sounds like the status quo. I don't mean to say that we shouldn't try to improve on that, but we've had ample opportunity to move context management away from the user and I haven't seen any progress in that direction.

Honestly, I don't like the idea of adding those features, both from an ideological and technical standpoint:

• As the person maintaining this library, I want to figure out the best design, get it to 1.0, then move on. If we expand the feature set, we make this harder to stabilize and open the door for adding in even more features. The slippery slope absolutely applies here.
• We should not be encouraging designs that hide OpenGL context switches, for a few reasons:
  • Switching the context is a fundamentally unsafe operation. If the graphics library manages contexts and can switch them at will, every operation becomes potentially unsafe when interacting with other graphics libraries that also implicitly manage contexts.
  • Context switching is expensive, and should never happen implicitly for the sake of performance.
• It's possible to completely disassociate an OpenGL context from the window, which lets you do cool things like rendering to multiple windows with the same context. I believe Glutin is moving in that direction (cc @zegentzy - correct me if I'm wrong). Explicitly tying the context to the window makes that design impossible.

[kvark]

@Osspial so we come down to something I mentioned previously - "raw-gl-context" library, which would be independent of this one. Library would abstract away GL context details of glfw/sdl/glutin/etc.

It's possible to completely disassociate an OpenGL context from the window, which lets you do cool things

FYI, I started that work in rust-windowing/glutin#942
@zegentzy definitely got further :) maybe they can give an update on how this is going?

[Osspial]

@kvark I'd be entirely fine with having a raw-gl-context library. However, I've got a lot of stuff on my plate right now, and I can't see myself maintaining that. I'll happily create and endorse the repo within rust-windowing, though (unless you'd prefer to have it in the gfx-rs organization), as long as someone steps up to manage it.