glow backend

[emilk]

Hi again, and thanks for a really nice looking library!

I was wondering if you have considered using (or adding) glow as the OpenGL backend in three-d?

Some direct benefits:

• No need for build.rs (I tend to shy away from libraries using it).
• No need to build and maintain the cross-platform OpenGL bindings yourself (though I guess most of that work is already behind you).
• You can use egui_glow instead of rolling your own.

The reason I ask is for egotistical reasons. I would love to be able to write an eframe app and then add a high-level 3D rendering library on top of it. And three-d looks like it could be a great candidate for such a library! In such a world eframe could focus on being a good framework for setting up a window, and three-d could focus on being a great 3D rendering library.

Of course we could instead build out the framework part of three-d to be as feature-complete as eframe, but that's a lot of work (for instance: eframe has a bunch of code in it to handle mobile text input on the web), and it would greatly detract from what three-d is: a 3D rendering crate.

There are likely subtleties here that I'm not seeing, but I thought I would at least throw out the idea!

I guess another way to phrase this issue is: do you think three-d could be made into a library, built on top of glow?

PS: even though I am the author of eframe I would love to throw it away if there was a good alternative.

[asny]

Thanks a lot! 👍 I'm glad you liked it, then I don't feel that bad doing shameless self-promotion 🙂

Also, I think it sounds like a great idea! 🚀 I would really like to integrate with other libraries and focus on rendering! I definitely don't want to make three-d into a framework, I only have the window part of the library to make it easy to get started and I had always figured that that was something people would replace with something more advanced, though I'm not sure it happens in practice. So I'm all in for integrating with eframe or any other framework for that matter. I guess eframe would depend on three-d, just as eframe depends on egui, or did I get that wrong?

About glow, I have definitely considered it. The reason why I don't use it is because it didn't exist 4 years ago when I started this project. I have even talked to grovesNL about that we are doing almost the same thing, though my focus was something more high-level and therefore I only implemented the gl functionality that I needed, whereas for glow, the gl functionality is an end goal in itself. The reason why I didn't change the backend is simply because I didn't have a very big incentive to do it. As you also point out, most of the work is already done, so there is more work in changing to glow. However, it shouldn't be a big task since all of the functionality is the same and even with almost the same naming.

Do you need anything else other than changing the backend to glow?

[emilk]

That's great to hear!

My current thinking is to leave three-d and eframe as unrelated crates that share a dependency on glow. Then an eframe user could add a dependency on three-d to get access to a high-level 3D rendering library. eframe creates the glow context, and the user would pass it to three-d. This keeps things very modular. For instance, a user can easily swap out eframe for another framework (e.g. tao).

I'd love to discuss it more – maybe find me on the egui discord and DM me!

[emilk]

Related: emilk/egui#1351

[asny]

The timeline is that I finish up the 0.11 release and then I start on this for the 0.12 release.

[asny]

@emilk Wasn't too big an effort, so I just merged it into master together with other changes in 4097290 . Will you test if it works for you? The entrypoint is Context::from_gl_context that takes an Rc to a glow context.

[emilk]

I will test!

[emilk]

I tested it, and it in emilk/egui#1407, and it works great! Thanks @asny !