[WIP-RFC] Pure GL Contexts

[kvark]

GL windowing system is a mess. Coming from Vulkan's model, it would be great to separate the concepts of GL contexts (as something that you can bind and issue GL commands with) and GL windows (as the main framebuffer destination, if any). Basically, this change comes from trying to implement the idea expressed in gfx-rs/gfx#1539 (comment)

What this PR has:

• GlContext trait is split into GlContext and GlWindowContext
• In addition to regular Context and HeadlessContext, there is a new PureContext type for such contents that have no surface attached to them (thus, no main framebuffer).
• PureContext is implemented for GLX, requiring GLX_ARB_create_context

If this idea sounds good to you, I can start looking into other platforms/APIs. In the worst case, I assume one can always work around the lack of pure context support by creating a hidden surface. Also, the source of offscreen-rendering-context might be helpful.

[tomaka]

Originally the split between HeadlessContext and Window existed in order to avoid windowing-related functions on a headless context.
However I don't think it's worth splitting at compile-time between "contexts that have a surface" and "contexts that don't". In fact I'd be more in favour of merging Context and HeadlessContext.

[kvark]

Thanks for taking a look!

Originally the split between HeadlessContext and Window existed in order to avoid windowing-related functions on a headless context.

That's a bit confusing to me because apparently HeadlessContext still has a surface (at least, the OSMesa implementation, which btw I think should just be a separate platform), it's just not attached to the display. Thus, most of the window-related stuff still applies.

However I don't think it's worth splitting at compile-time between "contexts that have a surface" and "contexts that don't"

What would be the downside of the split? Roughly half of the methods in GlContext trait don't make sense when there is no surface attached.

[tomaka]

What would be the downside of the split?

Well, the downside is code de-duplication.

I'm not against a structural change in the traits, but I'm not a fan of having to add even more unsafe no-really-tested code in the backends.

[kvark]

Well, the downside is code de-duplication.

Did you mean duplication? From my experience implementing this on GLX I found that most of the code is reused. It even looks better this way, check out https://github.com/tomaka/glutin/pull/942/files#diff-6e823a1677cbfc15c4b582bbbdb87614R140

[goddessfreya]

With {Separated,Combined,}Contexts, do you think this is still a necessary change, or has your use case been satisfied?
#1101

[kvark]

I'll have to get back to this and re-evaluate the state of the PR.

[goddessfreya]

Surfaceless contexts for EGL have been implemented on linux in 0.21. I get around to a glx implementation sometime.