"GLFW is an Open Source, multi-platform library for OpenGL, OpenGL ES and Vulkan development on the desktop. It provides a simple API for creating windows, contexts and surfaces, receiving input and events."
For those who wonder what GLFW is... if you want to play with OpenGL or Vulkan, make a graphics demo, or make a game, GLFW is a library that frees you from having to deal with the nuances of Win32/X11/etc, wrangles keyboard inputs and other things across platforms.
It is similar to LibSDL, but is more lightweight and GPU-centric. GLFW is designed more with greenfield projects in mind, whereas LibSDL was designed from the beginning to help with porting existing code. (They are both excellent libraries.)
So, it's sort of like GLUT was? (is?) I only messed around with 3D rendering a little back in the very early 2000's, but from what I remember, GLUT made everything much easier.
Yes, it's kind of like GLUT, although it covers fewer functionalities. It focuses only on abstracting the OS specific parts like keyboard/mouse input and window/graphics context creation. GLUT also offered things like rendering fonts, teapots and additional functionalities.
I got to know of glfw because a few GUI libs which embed Flutter (in Rust or Go) use it. Maybe it's just a hyperbole, but will this release help those efforts?
GLFW, SDL, and SFML are on a scale from "lightweight" to "heavyweight". SFML is, by far, the largest, heaviest, and most opinionated of the three.
GLFW is not much more than platform abstraction for multimedia (windows, input, OpenGL/Vulkan context creation, timing). Notably it is missing any kind of audio support, but you probably want to ues FMOD, Wwise, or iirKlang anyway.
SDL is all of that, plus various utilities for porting and some platform abstractions that are no longer needed. For example, logging, assertions, blitting, endian conversion, file abstraction, threads and atomics. There are a few associated helper libraries designed to work with SDL, like SDL_image, SDL_ttf, and SDL_mixer. These are optional.
SFML is all of that, plus the interface is written in C++, there's all sorts of things like sprite drawing, texture loading, and audio systems mixed in, plus a bunch of extra random functionality like HTTP clients, OpenGL wrappers, etc.
SDL is the oldest of the three. My perspective is that if you look at SDL and think, "Wow, this does a lot of stuff that is kind of weird and old, maybe I don't need all of that", then you would invent GLFW. If you looked at SDL and thought, "I want something bigger, more, more, more, with a C++ interface, consume the world!" Then you would invent SFML.
I have some strong opinions here, which are probably coming across. I see developers who say, "I want to make games, that means low-level, so I'm going to learn Win32," and I try to prevent them from wasting time learning APIs, steering them towards one of these libraries. On the other hand, I think SFML is a big mess that tries to do everything, and it's a lesson in why it's easy to make bad C++ APIs. I mean, jeez, it has "class RectangleShape" which inherits from "Shape" which inherits from "Drawable". It makes me want to puke.
Personally I like SFML because you can just slap it into a quick project and get things rolling quickly but I agree with it trying to handle too much. I suppose the main reasoning was that it was intended for creating video games. At least you can pick and choose different headers ¯\_(ツ)_/¯
Excellent! I've been using GLFW_TRANSPARENT_FRAMEBUFFER for over a year, but kept having to do builds out of Git to get support. It will be nice when this new library trickles into Linux distros over the next year.
Nice to see this is still in development. I wrote GLWF bindings for two languages and it was pretty easy to grok. It's also absolutely essential if you want to have an UI in a language without support for GUIs (like golang). Just use the OpenGL backend for the immediate mode UI lib of your choice (dear-imgui, nuklear, ...) and GLFW for the window setup and you're golden.
Back when I was doing a lot with this stuff, GLUT was effectively dead. Stuff like MacOS HiDPI surfaces wasn't doable without going well outside of what GLUT wanted to help you with. GLFW has been under active development over that time period, unifying baseline OpenGL, OpenGL ES, and Vulkan stuff to build upon.
Indeed, GLUT is not in active development (I would not say that it is "effectively dead" but rather that it "crystallized into a perfect form", but I digress). However, I was asking about "freeglut", which is a different thing, which is actively developed: last commit on 2019-03-26 dropped some unnecessary dependencies, for example.
I remember GLUT having some pretty significant deficiencies last time I looked at it. I guess FreeGLUT has added support for stuff like Unicode, high-DPI displays, etc... in the intervening years?
I just use freeglut to open a window and throw opengl into it, in a more or less portable way. The "gui" and "font" parts of freeglut are not really very useful (and they are missing in glfw anyway). Thus, unicode and high-dpi issues should be of no concern: as long as you can draw to your window and receive user input, what else do you need? What do you mean exactly by high-dpi "support"?
You have to explicitly opt into a Retina display context on MacOS in order to get a window into which you can render at high DPI (2x the physical dimensions). You cannot mimic this with transform matrices; the render target will be rasterized at low-DPI and interpolated.
So, yes, high-DPI issues very much exist, and GLFW does the right thing.
Very excited for this release! GLFW is part of the foundation for a UI framework we're building called Revery [1] and there are several features in 3.3 that will be useful for us - transparent framebuffers, headless backend via OSMesa (important for CI / automation), and high-DPI improvements.
GLFW takes a lot of the pain out of cross-platform GPU development, and I've found the API simple and intuitive to work with. For those looking to play with it - the LearnOpenGL tutorial series [2] is excellent, and uses GLFW for managing a window and getting an OpenGL context.
Yeah I'm kinda surprised by this. You would think there would be some industry support for emulating graphics/gpgpu pipelines to make cloud CI cheaper and simpler, but maybe it's just a much harder problem than I imagine -- to the point where mocking opengl or using dedicated hardware makes more sense.
Ah, that's too bad! I've been hunting for ways to get better integration tests on CI for Revery.
Would like to have image-based verification for certain classes of tests, and we use Azure CI pipelines - seems their VMs don't have hardware support at all for OpenGL (on any platform).
34 comments
[ 5.1 ms ] story [ 89.6 ms ] threadIt is similar to LibSDL, but is more lightweight and GPU-centric. GLFW is designed more with greenfield projects in mind, whereas LibSDL was designed from the beginning to help with porting existing code. (They are both excellent libraries.)
Edit: upon initial inspection it appears SFML is similar to SDL, which provides support for other features such has networking, audio etc.
GLFW is not much more than platform abstraction for multimedia (windows, input, OpenGL/Vulkan context creation, timing). Notably it is missing any kind of audio support, but you probably want to ues FMOD, Wwise, or iirKlang anyway.
SDL is all of that, plus various utilities for porting and some platform abstractions that are no longer needed. For example, logging, assertions, blitting, endian conversion, file abstraction, threads and atomics. There are a few associated helper libraries designed to work with SDL, like SDL_image, SDL_ttf, and SDL_mixer. These are optional.
SFML is all of that, plus the interface is written in C++, there's all sorts of things like sprite drawing, texture loading, and audio systems mixed in, plus a bunch of extra random functionality like HTTP clients, OpenGL wrappers, etc.
SDL is the oldest of the three. My perspective is that if you look at SDL and think, "Wow, this does a lot of stuff that is kind of weird and old, maybe I don't need all of that", then you would invent GLFW. If you looked at SDL and thought, "I want something bigger, more, more, more, with a C++ interface, consume the world!" Then you would invent SFML.
I have some strong opinions here, which are probably coming across. I see developers who say, "I want to make games, that means low-level, so I'm going to learn Win32," and I try to prevent them from wasting time learning APIs, steering them towards one of these libraries. On the other hand, I think SFML is a big mess that tries to do everything, and it's a lesson in why it's easy to make bad C++ APIs. I mean, jeez, it has "class RectangleShape" which inherits from "Shape" which inherits from "Drawable". It makes me want to puke.
I am using freeglut for casual opengl code, and I see no problem with it. Is there anything that I am missing?
So, yes, high-DPI issues very much exist, and GLFW does the right thing.
GLFW takes a lot of the pain out of cross-platform GPU development, and I've found the API simple and intuitive to work with. For those looking to play with it - the LearnOpenGL tutorial series [2] is excellent, and uses GLFW for managing a window and getting an OpenGL context.
Thank you maintainers for your work on it!
- [1] Revery: https://github.com/revery-ui/revery
- [2] LearnOpenGL: https://learnopengl.com/Getting-started/Creating-a-window
[1]: https://mesamatrix.net/#Version_OpenGL3.3-GLSL3.30
Would like to have image-based verification for certain classes of tests, and we use Azure CI pipelines - seems their VMs don't have hardware support at all for OpenGL (on any platform).
[1]: https://en.wikipedia.org/wiki/Glossary_of_computer_graphics#...
https://github.com/bkaradzic/bgfx
Hard to know why this bug had to wait so long for a fix. Where are the delays coming from?