Here is a small “post-mortem” post about glium. It is here to express my feelings about what went
wrong with glium. This post is also here because I need some advice from you about what the future
of glium should be.
Usually a post-mortem is supposed to contain the positive aspects of a project. In other words,
what went right. But I’m generally a perfectionnist person and am very critical of my work, so
I don’t really know what to put in that category.
Most people report that glium is a huge improvement over raw OpenGL, which I think is true. So
that’s a good point. But I don’t see any aspect where the development of glium particularly shined
compared to another library.
Let’s jump to the negative aspects, which are the most interesting part.
What went wrong
Drivers are still crippled with bugs
I knew that OpenGL drivers were crippled with bugs when I started glium, but I didn’t know at which
degree. Glium was supposed to be a safe layer above the drivers and fix all the safety bugs that
are encoutered. That’s why glium contains lots of codes like this
In reality the situation is too catastrophic, and it’s almost impossible to keep that initial goal
of fixing driver errors. I have the feeling that some driver writers barely read the specifications,
and the fact that online documentation (like docs.gl) is filled with mistakes doesn’t help.
An anecdote is that the first time I ran unit tests with vulkano I was amazed by the mere fact that
it worked. Glium’s tests happen to randomly fail because of driver bugs.
The more recent the OpenGL feature the more likely it has bugs in it, even with major vendors.
Some very recent extensions are barely usable with some drivers.
I should have accepted that situation and sticked with well-established OpenGL features that are
known to work well everywhere, instead of exposing the entirety of OpenGL.
Overlapping with Vulkan
The most recent OpenGL features (like persistent-mapped buffers or bindless textures) are
overlapping with what Vulkan proposes. The current situation in 3D rendering is that if you want
low-level control over what’s happening then you should use Vulkan, and if you want to have a
high-level API or support older hardware or work on the web then you should use OpenGL.
Before Vulkan was released, it made sense to expose some low-level functionnalities in OpenGL
itself, because high-performance games need low-level control.
But now it’s no longer useful. These capabilities only work on recent hardware anyway, and are too
dangerous to ever be exposed by a browser with WebGL.
Had I know that (I’m still a bit bitter about the fact that the development of Vulkan was entirely secret before its release), I wouldn’t have bothered with anything more recent than OpenGL 4.0/4.1 in glium.
Vulkan supports hardware released in 2012 or more, so it’s not like it’s a niche technology.
Even if desktop OpenGL fades away over time, there’s still a large market for OpenGL on the web and
on mobile devices. Only very recent mobile phones and tablets can support Vulkan.
Lots of unfinished areas
Overall, glium has a ton of unfinished elements. Textures and buffers (the basic blocks of OpenGL)
still haven’t got a complete API.
The reason is simple: when I started glium (and still today), there was no real reference for how
to design an API. I built an API, then changed my mind and changed it, then changed my mind again.
Each change was justified, but I wouldn’t have lost that much time if I knew from the start how to
design things in Rust.
Flooded with questions
One aspect that I didn’t anticipate is that I’m now “flooded” with questions about glium.
By e-mail, on IRC (some of them in private), and with issues. And it’s tiring. Sometimes I
purposely don’t answer questions because I don’t have the motivation to do so, but I always feel
bad when I do that.
I can put these questions in three categories:
- “How do you do <thing in OpenGL>?”, to which my answer is almost always that glium’s API doesn’t
allow that yet, but they can use <hacky solution> instead for now.
- “I have this problem with glium”, to which my answer usually is: I know that this problem exists, but
fixing it requires a lot of work.
- “How do you do <thing in 3D rendering>?”. Since glium is such high-level and has a tutorial
oriented towards people who don’t know 3D rendering, I also get many questions about 3D rendering
in general. I generally answer these questions as well, because I consider it rude to answer
that they should ask someone else.
This could be improved by writing a FAQ and a real-world example of how to use glium. However
these take time and aren’t easy to write. In vulkano, I solved the problem by not really
communicating about the library. I started writing a vulkano tutorial, but didn’t say a word about
it. I also clearly say everywhere that vulkano isn’t ready yet. This is maybe a more cynical
solution, but so far it avoided me having to answer (annoying (sorry)) questions.
Failed to attract code contributors
The initial reason why I talked about glium on reddit and on the forum was to hopefully
I was hoping that people could help me, especially people experienced in OpenGL.
But after a few months, I still didn’t get any contribution to anything else but the documentation.
I realized that it’s because the core of the library is far too complicated. With all the API
reworks things began to be more and more messy, and I totally understand that people don’t want
to dive in this kind of code.
Since then the situation improved a bit, and I have had several features implemented only thanks
to people other than me. But unfortunately I think that I’m still the only person to understand
how that library is supposed to go forward, at least before this post. Glium is too much of a black box,
and that’s obviously bad.
I think that a partial rewrite would be necessary, in other words start from scratch but
copy-paste code from the old library when possible. I don’t really have the time however, so in
the meanwhile glium is in that delicate situation where it’s bad enough that I want to throw it
away, but not bad enough that people don’t use it.
Thanks for reading.
Let me know what you think about all this, and what you think should be the future of glium.