expose the raw field of context

[coderedart]

i'm learning OpenGL and there's a lot of modern opengl functions/features that i would like to try like DSA or MultiDraw or Indirect rendering. but glow doesn't have most of these functions yet.

but if the core context was exposed either through an unsafe function or by just making the raw field of the Context Struct public, i can just use that to try out all the new latest stuff.

[grovesNL]

I'd prefer to add these functions to glow instead if possible.

One problem with exposing raw is that the current bindings/binding generation is meant to be an internal implementation detail. e.g. if we change how bindings are generated somehow (function names, types, fallbacks between versions/extensions, which parts of the GL API are included, etc.) then we might break any crates relying on raw

[coderedart]

Can we have a sort of contributing.md file ? would help some new people to know how to start contributing as this seems like one of the easiest rust projects to contribute to, especially when they are already familiar with opengl.

[grovesNL]

Yeah absolutely :+1: I'll try to create one sometime soon

[coderedart]

oof, 3 months is a long time. but just wanted to see if there is some kind of progress related to separating platform specific functionality https://github.com/grovesNL/glow/issues/76#issuecomment-576321623 . pretty much none of the modern opengl functions exist in webgl(2) and they will all be unimplemented!().

if there's a sort of winit (platformEXT trait) functionality, lets say DesktopEXT, that will allow people to contribute without having to worry about webgl or openglES. the core HasContext can have upto ES or webgl level of core functionality, and the DesktopEXT can have everything up to the latest 4.6 functions. people who use functions from this trait can check whether their minimum opengl core vesion actually has those functions.

Although, I don't know how something like gl functions that are in ARB extensions are dealt with. maybe another trait? where everything is allowed. a good example is bindless textures. to quote khronos wiki page not all 4.3 hardware can handle bindless textures. The OpenGL ARB decided to make the functional optional by having it be an extension. It is implemented across much of the OpenGL 4.x hardware spectrum. Intel is mostly absent, but both AMD and NVIDIA have a lot of hardware that can handle it. .

I only added some dsa functions in https://github.com/grovesNL/glow/pull/191 , and before i start playing with more stuff like multidraw or indirectdraws or bindless textures, I wanted to see if i could avoid polluting webgl context code which will be a lot of unimplemented!() and unnecessary autocompletions.

[TannerRogalsky]

I would suggest that a trait like that might not belong in this crate which, as you've pointed out, is more about bridging the gap between OpenGL and WebGL than creating a Rusty interface for all of OpenGL. Personally, I like that, generally, the API surface defined in this crate approximates the features that are usable on both platforms. I think I'd rather see a, for example, glow-gl4-ext crate that implements the additional functionality (although at that point I'm not sure why you wouldn't just use the generated GL bindings directly).

[coderedart]

ah. my bad. my use case of glow is to just have a clean wrapper instead of raw gl bindings with raw pointers and casts flying around everywhere. i asked in the rust gamedev discord and was told that glow allows stuff that is technically not a strict subset of the es/web/desktop gl versions. like https://github.com/grovesNL/glow/pull/175/commits/c0d566ec7bbbd44d7e9157135577edeac6e65c8c . either the trait way or a separate crate glow-gl4-ext way is fine for me.

[TannerRogalsky]

Yeah, you're 100% right that there are some places where the practical desire for this to be generally useful has overridden the aspirational desire to represent the API available on both platforms. My personal feelings are that a push to implement all of gl46 in this pseudo-Rusty style that glow does might be too big a departure from the generally stated goal of this crate.

But, hell, I'm not the maintainer. :P

[PolyMeilex]

ah. my bad. my use case of glow is to just have a clean wrapper instead of raw gl bindings with raw pointers and casts flying around everywhere. i asked in the rust gamedev discord and was told that glow allows stuff that is technically not a strict subset of the es/web/desktop gl versions. like https://github.com/grovesNL/glow/pull/175/commits/c0d566ec7bbbd44d7e9157135577edeac6e65c8c . either the trait way or a separate crate glow-gl4-ext way is fine for me.

It's same for me, I don't use the webgl side of glow at all 😅, and I'm well aware that it's the whole point of this crate

[grovesNL]

@coderedart for now I think it's fine to add them to the regular HasContext trait, and panic in the web backend implementations for those functions.

We could always consider restructuring it later if this eventually causes problems (e.g. bloating the web backend too much, too confusing when referencing documentation, etc.). In that case we could probably move them into a separate GL-only trait (possibly also behind a feature that's off by default or separate crate).

I'd also like to add doc comments to each function to clarify which versions/backends/extensions support it, which would be a simple way to improve ergonomics in general.