grovesNL
Where does glow sit in an app stack?
I was looking at egui-glow and wondered how does glow fit in in the amalgam of raw-window-handle, winit, egui, gl-generator, glutin, etc. This would be really nice to mention in the readme. The most common problem with Rust crates around these topics for me is trying to figure out where does each one sit in the graphical application stack. What parts are they designed to take care of, and what needs to be provided by others?
Do I understand right that glow is roughly a replacement for gl-generator? Except everything is implemented by hand rather than generated, so that it offers the common sub-set of the chosen GL APIs? Limiting to the common sub-set of the GL APIs was a little unclear until I saw it spelled out at https://github.com/grovesNL/glow/issues/76 . Something like this (if it's correct) in the readme would help understand the design rational better:
glow offers hand-written API for selected OpenGL features that are available in all of OpenGL 2.x and later, OpenGL ES 3.0, and WebGL, abstracting away the little differences between the versions of the OpenGL APIs.
If my app is using gl-generator and glutin, can I still use a lib that uses glow for its own rendering in the same GL context as me?
Do I understand right that glow is roughly a replacement for gl-generator?
I think it would be more accurate to say that this attempts to be a platform-agnostic GL API. gl-generator is great for exposing all the native GL functions. In fact, this project uses a similar project called phosphorous to generate it's native GL bindings. But does not attempt to do the same for WebGL or allow the consumer (you) to not care which platform you're building for.
The most common problem with Rust crates around these topics for me is trying to figure out where does each one sit in the graphical application stack. What parts are they designed to take care of, and what needs to be provided by others?
I'm deeply sympathetic to this and I think that the Rust ecosystem, generally, can do better here. But I'd also suggest that glow is a relatively simple, relatively unopinionated library. For it to describe where it sits in the application stack would be contrary to the the goal of being foundational and not caring what's built on top of it.
There are some projects that support glow as one of many backends. They would perhaps be the best places to explain how they think about this project against other similar ones but in order to get into that territory you would have to be committed to learning some of the internal implementation details of some fairly complex projects.
I don't know that there's a simple answer here. It doesn't seem like you're chasing simplicity, though, or you'd be using a more batteries-included solution rather than trying to roll your own. Maybe we're best just to embrace the complexity for those for whom it's appropriate that they're looking at glow in the first place.
If my app is using gl-generator and glutin, can I still use a lib that uses glow for its own rendering in the same GL context as me?
That would probably not be ideal. The examples include how to use glutin but, for native platforms. If I can be prescriptive, I tend to write a "native" window that uses glutin to acquire a context and a "wasm" window that uses wasm-bindgen and then they both pass a Context back to the app.
Thank you.
For where does glow sit in, I'm thinking of questions like:
- Does glow offer me a choice between several OpenGL API flavors, or is it offering a single API abstracted from them all?
- Does "(avoid) target specific code" refer to OpenGL APIs, operating systems, window systems, glue layers (EGL, WGL, GLX, etc.), or?
- Does glow create GL contexts? If not, does it care how one is created or what kind of context? Do I need to use a specific crate for it?
- How does glow load/resolve symbols from the native OpenGL libraries, as in, what is required from the user?
I believe a couple sentences along these lines added to the readme would help people decide whether they want to look into glow further. Linking to the examples, or even mentioning they exist, would be nice (I didn't think of looking for them, I went straight to your docs). Looking at phosphorus, my first question was "why is it titled next generation, how is it different?". Given its readme as it is, I'd skip it without a second thought.
I could find out all that by studying the sources, but first I would need to be convinced that the effort is likely to be fruitful.
Consider this issue as bug report on the readme, asking for a little more overview, please. I think it would help sell glow better.
(Personally, I am currently interested specifically in OpenGL ES 3 on EGL in native Linux, because desktop Linux is the only platform I use and my project is for me only. Portability generally tends to make libraries harder to use in my experience. Right now I'm trying to figure out if I can use egui-glow, or if I need to write my own egui renderer. It's good to hear that glow itself is not limiting my options here.)
A suggestion:
glow provides a single, thin GL-like API that is implemented for desktop OpenGL 2.x and later, OpenGL ES 2 and 3 or WebGL according to the GL context you provide. You don't need to care about the differences between the OpenGL flavors, but creating the GL context and loading OpenGL symbols from the native libraries is your responsibility to do any way you like.
See examples:
- hello: initialization example for wasm, glutin-winit and SDL2
- howto: common actions with glow (SDL2)