Should I use glium or raw OpenGL calls?

Hi! :grinning:

I'd like to convert just 30 Kb of C++ code to Rust. It uses OpenGL and some simple, custom font functions (getting text onto the screen with a chosen Windows font). It will maybe grow to 100 or 200 Kb relatively easy GUI code that makes use of OpenGL.

When I'm going to use glium, these limitations, taken from the github page, will surely not be a problem?

  • Stack overflows inside the compiler
  • internal compiler errors
  • "one-hour compile time"

I looks like a bit too pessimistic project limitations? I'm asking because I'm a bit confused, and I think I could manage to get it done with raw OpenGL calls, too. I didn't have a problem doing such a thing in Golang.

Does anyone know whether using glium is a good or a bad idea?

Thanks a lot!

glium is fine for most any OpenGL project. It provides a safe interface over OpenGL, which is its biggest strength. On the other hand, the crate is no longer under active development; don’t expect to see many awesome new features coming in the future.

gfx is an alternative, and it provides a similar safe interface. It is under heavy development to redesign the internals around Vulkan. The stable gfx is also in maintenance mode though, just like glium. The main draw to the new gfx (called “LL” for “Low Level”) is that it does not restrict your application to a single backend like OpenGL or Vulkan. Instead, the backends are interchangeable, while the front end remains mostly the same. Its goal is to make applications portable to multiple platforms, regardless of which backend is used; Vulkan, DirectX 12, Metal, ...

Anyway, if you’re ok using the unsafe OpenGL bindings, go for it! Just consider yourself warned that the interface is unsafe, and you can easily run into undefined behavior. glium or stable gfx will provide a safe interface and low overhead, though. Choosing between the two is mostly a matter of preference for the APIs, and maybe depending on other crates that use one or the other.

1 Like