GLFW 3.3 Is Released(glfw.org)
glfw.org
GLFW 3.3 Is Released
https://www.glfw.org/Version-3.3-released.html
34 comments
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 would say that any time you are using GLUT for new projects, you really should be using GLFW or LibSDL instead.
I mainly see GLFW used as a modern, if somewhat more bare bones (no font rendering, no event loop, etc), variant of GLUT.
"is", as long as you consider FreeGLUT as being GLUT.
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?
How does GLFW compare to SFML?
Edit: upon initial inspection it appears SFML is similar to SDL, which provides support for other features such has networking, audio etc.
Edit: upon initial inspection it appears SFML is similar to SDL, which provides support for other features such has networking, audio etc.
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.
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.
Thank you. How about SDL 2.0? It was a major rewrite - is it modern enough?
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 ¯\_(ツ)_/¯
I can't agree more, especially with the last part of inheritance nonsense.
SFML is much "fatter", it handles graphics and even audio and networking.
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.
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
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
Sadly Mesa's software renderers seem to have topped out at OpenGL 3.3[1] :(
[1]: https://mesamatrix.net/#Version_OpenGL3.3-GLSL3.30
[1]: https://mesamatrix.net/#Version_OpenGL3.3-GLSL3.30
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).
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).
Eh, 3.3 Core is still pretty darn capable. 4.0+ mostly just added tessellation/compute shaders & quality-of-life and/or AZDO[1]-style features.
[1]: https://en.wikipedia.org/wiki/Glossary_of_computer_graphics#...
[1]: https://en.wikipedia.org/wiki/Glossary_of_computer_graphics#...
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.
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.
"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."
As a nice complement to GLFW, there's also bgfx which can be configured to use GLFW:
https://github.com/bkaradzic/bgfx
https://github.com/bkaradzic/bgfx
Can somebody explain what are the advantages of glfw over freeglut? (other than the non-issue of "being" old)
I am using freeglut for casual opengl code, and I see no problem with it. Is there anything that I am missing?
I am using freeglut for casual opengl code, and I see no problem with it. Is there anything that I am missing?
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.
So, yes, high-DPI issues very much exist, and GLFW does the right thing.
[deleted]
Finally, I was waiting for this release, they fixed an annoying click event bug on Linux.
Hard to know why this bug had to wait so long for a fix. Where are the delays coming from?
Hard to know why this bug had to wait so long for a fix. Where are the delays coming from?
Dynamic loading of backends, i.e. supporting X11 and Wayland with the same build (PR #1338) didn't make it :(
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.)