6 ms·

GLFW 3.3 Is Released

124 points by dmitshur 7y ago

eikenberry 7y ago
"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."
klodolph 7y ago
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.)
- childintime 7y ago
  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?
- kbenson 7y ago
  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.
  - electricslpnsld 7y ago
    I mainly see GLFW used as a modern, if somewhat more bare bones (no font rendering, no event loop, etc), variant of GLUT.
  - skocznymroczny 7y ago
    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.
  - Crinus 7y ago
    "is", as long as you consider FreeGLUT as being GLUT.
  - klodolph 7y ago
    I would say that any time you are using GLUT for new projects, you really should be using GLFW or LibSDL instead.
- muterad_murilax 7y ago
  What does the FW in GLFW stand for?
  - kirke 7y ago
    GLFrameWork
- iamcreasy 7y ago
  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.
  - floatboth 7y ago
    SFML is much "fatter", it handles graphics and even audio and networking.
  - klodolph 7y ago
    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.
    - iamcreasy 7y ago
planteen 7y ago
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.
minxomat 7y ago
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.
enriquto 7y ago
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?
- deleted 7y ago
  [deleted]
- eropple 7y ago
  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.
  - VirtualAirwaves 7y ago
    What?!
  - enriquto 7y ago
    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.
    - jandrese 7y ago
      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?
      - enriquto 7y ago
        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"?
bryanphe 7y ago
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 https://github.com/revery-ui/revery - [2] LearnOpenGL: https://learnopengl.com/Getting-started/Creating-a-window https://learnopengl.com/Getting-started/Creating-a-window
- genpfault 7y ago
  Sadly Mesa's software renderers seem to have topped out at OpenGL 3.3[1] :( [1]: https://mesamatrix.net/#Version_OpenGL3.3-GLSL3.30 https://mesamatrix.net/#Version_OpenGL3.3-GLSL3.30
  - glalonde 7y ago
    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.
  - bryanphe 7y ago
    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).
    - genpfault 7y ago
      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#azdo https://en.wikipedia.org/wiki/Glossary_of_computer_graphics#...
binarycrusader 7y ago
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
floatboth 7y ago
Dynamic loading of backends, i.e. supporting X11 and Wayland with the same build (PR #1338) didn't make it :(
jokoon 7y ago
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?

124 points by dmitshur 7y ago

"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."

klodolph 7y ago

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.)

childintime 7y ago
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?
kbenson 7y ago
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.
- electricslpnsld 7y ago
  I mainly see GLFW used as a modern, if somewhat more bare bones (no font rendering, no event loop, etc), variant of GLUT.
- skocznymroczny 7y ago
  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.
- Crinus 7y ago
  "is", as long as you consider FreeGLUT as being GLUT.
- klodolph 7y ago
  I would say that any time you are using GLUT for new projects, you really should be using GLFW or LibSDL instead.
muterad_murilax 7y ago
What does the FW in GLFW stand for?
- kirke 7y ago
  GLFrameWork
iamcreasy 7y ago
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.
- floatboth 7y ago
  SFML is much "fatter", it handles graphics and even audio and networking.
- klodolph 7y ago
  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.
  - iamcreasy 7y ago

planteen 7y ago

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.

minxomat 7y ago

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.

enriquto 7y ago

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?

deleted 7y ago
[deleted]
eropple 7y ago
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.
- VirtualAirwaves 7y ago
  What?!
- enriquto 7y ago
  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.
  - jandrese 7y ago
    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?
    - enriquto 7y ago
      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"?

bryanphe 7y ago

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 https://github.com/revery-ui/revery - [2] LearnOpenGL: https://learnopengl.com/Getting-started/Creating-a-window https://learnopengl.com/Getting-started/Creating-a-window

genpfault 7y ago
Sadly Mesa's software renderers seem to have topped out at OpenGL 3.3[1] :( [1]: https://mesamatrix.net/#Version_OpenGL3.3-GLSL3.30 https://mesamatrix.net/#Version_OpenGL3.3-GLSL3.30
- glalonde 7y ago
  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.
- bryanphe 7y ago
  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).
  - genpfault 7y ago
    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#azdo https://en.wikipedia.org/wiki/Glossary_of_computer_graphics#...

binarycrusader 7y ago

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

floatboth 7y ago

Dynamic loading of backends, i.e. supporting X11 and Wayland with the same build (PR #1338) didn't make it :(

jokoon 7y ago

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?