The Glium Library – Safe OpenGL in Rust | Hacker News Reader

The Glium Library – Safe OpenGL in Rust

medium.com

163 pointsbpbp-mango26 comments

The library author feedback on the Rust ecosystem shortcomings is pretty interresting too : https://internals.rust-lang.org/t/production-user-research-s...

Excellent writing on the pitfalls of OpenGL and how to circumvent those. Applies to any OpenGL programming, not just Rust also.

Here's hoping Vulkan will fix these issues in the future and Apple also adapting this platform.

It seems unlikely Apple would adopt Vulkan at this point. Maybe if Vulkan came out a year ago. The only thing that might convince them is if big developers such as Blizzard and whoever else decides to write PC/Android games in Vulkan. EA's Dice was already pushing for Mantle, which is now part of Vulkan, so maybe most of EA's games could be written in Vulkan in the future. That might get Apple to adopt it, even if 80% of iOS games will use Metal instead of OpenGL ES by that point.

Unity and Unreal already support Metal and I imagine other engines are in the process of doing the same.

With all major engines on Metal, Apple has nothing to lose by not supporting Vulkan, other than a few indie devs that stay away from engines.

Oddly not linked in the article, the source:

https://github.com/tomaka/glium

It's linked in the third paragraph.

Another cool thing he mentions is that it does something sort of like React's diffing.

When you tell Glium, "make me these three polygons, add a light source, apply a transform matrix", it optimizes the number of OpenGL calls it needs to do, and the kinds thereof, and puts them in the right order to run most efficiently.

Like React, it optimizes state changes required for speed to get a view from one state to another.

The fact that Glium needs to do this demonstrates how flawed the state-wrangling in OpenGL has become. Vulkan can't come fast enough.

A couple years ago I was trying to teach myself OpenGL, and I failed miserably for that exact reason, plus bad function naming conventions.

The weirdest thing about OpenGL is that you sometimes have to run one function before another function, for no good reason, but it gives you a giant performance boost.

Sounds great! Dare I try it on windows now? (The last n times I did ... things did not work out).

Kudos for taking also the texture colorspace issue into account - I've found people new to real time programming tend to find this initiaĺly one of the most bysantine minutiae one absolutely needs to get right

I didn't have any problems running examples from tutorial at http://tomaka.github.io/glium/tutorials/01-getting-started.h... on windows

If there are issues you could report them on https://github.com/tomaka/glium/issues

Thanks for the encouragement - I downloaded Rust 1.2 for windows and finally I got this working out of the box. Yay! (still had weird problems at Rust 1.0 beta...)

First time I've heard about it in any writings. Put onto my list how to implement it. Any good articles on the RGB vs sRGB colorspace issue in OpenGL ?

Briefly and massively simplifying: Unless otherwise specified, sRGB is the default storage and display colorspace for most digital applications dealing with RGB image data (excluding video)

https://en.wikipedia.org/wiki/SRGB

However, one cannot do computations on an image in sRGB colorspace since the colorspace is not linear - the values will turn out wrong. I.e. imaging algorithms expect source data to be in linear colorspace, and if fed sRGB data the result will turn out more or less wrong.

Thus, when doing any weighting calculations etc. on a set of samples the samples must be in linear (e.g. RGB) colorspace.

Your OpenGL implementation may or may not handle this automatically for you if you specify the image to be in one of the sRGB texture formats. https://www.opengl.org/registry/specs/EXT/texture_sRGB.txt

So, in the general sense, if doing any handcoded imaging routines, and reading e.g. PNG image, one needs to convert it to linear colorspace before processing, and back to sRGB before writing to disk/displaying.

Linear vs gamma space is not an OpenGL specific problem. Also the decode/encode doesn't require 3D API support, it can also be done in the pixel-shader (decode from gamma to linear when sampling color textures, and encode back into gamma during a post-effect pass that most engines have anyway).

'The importance of being linear' is the best introduction to the topic I know: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html

This is a fantastic example of how to make a foreign API safe and neat in a Rust-y kind of way. The author has done a great job with hlua too (see previous blog post).

> The “untextured objects” example of AZDO: drawing 64x64x64 individual moving objects. The glium version runs at approximately the same speed as the original pure OpenGL example.

Seems like Rust is making good progress (emphasis mine). I really should take the time to learn this language.

The fact that it runs at approximately the same speed isn't really important. You would get the same result with any language.

The AZDO examples show what the most optimized OpenGL techniques are, and I just wanted to show that you can do the same thing with glium as with raw OpenGL.

That being said, you should still try Rust!

I'm using it to render cocos2d-x's c3t model, https://github.com/linuxaged/newton

This seems fantastic compared to my experiments in C + glut. Great work!

The API has macros to automatically generate type boilerplate. Very clever

So, Rust is ready for writing high performant games?

I don't know if it is, but it doesn't, it doesn't prevent people from trying. There is a community of rust game developer and a framework dedicated to game developpement : piston (http://www.piston.rs/).

Also a link related to game developement in rust : https://www.reddit.com/r/rust_gamedev

Semi-unrelated: The set of themed names around Rust will make it fun when and if a Rust game become available on Steam — “Today <game name>, a <game type> written in Rust with the Piston framework became available on Valve’s Steam game marketplace." It’s a steampunk fan’s dream.

And just imagine if they rewrote Rust in Rust! :P

Why not :)? Seems like a great fit to me, we'll see in the long run though.

Why not? I hope it will really shine in combination with Vulkan though, not with OpenGL.

Reply on news.ycombinator.com