Rationale for removing
From GLFW
This page collects more detailed rationales for why some features of GLFW 2.x have been removed from the upcoming 3.0 release.
Contents |
Threading support
As threading APIs go, the GLFW one is fairly primitive, it's under-used, it takes time away from the focus of GLFW (i.e. context, input, window), there are better threading libraries available (or where there aren't, they should be encouraged), the threading bits are almost entirely separate from the rest of GLFW (which is thread-unsafe), and native threading support is coming in both C++0x and C1X.
If you wish to use these facilities but your compiler doesn't yet support them, see the TinyThread++ and TinyCThread projects created by the original author of GLFW.
The tentative plan for 3.0 is to let the application plug an existing threading API into GLFW, using the GLFWthreadmodel struct, to make it (more) thread safe. This interface would be a lot smaller than the existing API and by default it will use a model that does nothing. Most applications will most likely keep calling GLFW only from the main thread.
If someone at this point wishes to step forward and offer to write a better threading API for 3.0, please make it a standalone project instead. There will be no technical reason to tie such a library to GLFW (see above) and there is no reason to keep users of freeglut, SDL or another library from having equal access to it.
Image and texture support
The image loading support present in GLFW 2.x only supported the Targa image format, making it mostly useful for beginner level examples. To become of sufficiently high quality to warrant keeping it in the 3.x series, it would need not only to support many other formats, but also modern extensions to the OpenGL texturing facilities. This would either add a number of external dependencies (libjpeg, libpng, etc.), or force us to ship inline versions of these libraries.
As there are already libraries doing this, it seems unnecessary both to duplicate this work and to tie this duplicate to GLFW. Similar libraries, such as freeglut and SDL, could presumably also gain from such a library. Also, there is no inherently platform-specific part of such a library, as both OpenGL and libc I/O are available wherever GLFW is.
If someone at this point wishes to step forward and offer to write a better image and texture API for 3.0, please make it a standalone project instead. There is no technical reason to tie such a library to GLFW (see above) and there is no reason to keep users of freeglut, SDL or another library from having equal access to it.
Unicode character up
This is an artifact of the origin of GLFW, i.e. being developed in English by a Swede. However, many keyboard layouts require more than one key to produce characters with diacritical marks. Even the Swedish keyboard layout requires this for uncommon cases like ΓΌ.
Use of stdcall for Windows DLL
GLFW is being developed in C, not Pascal. Removing this means there's one less thing to get wrong, i.e. the requirement to mark all callback functions with GLFWCALL.
Win32 MBCS API support
Since the use of the Unicode version of the API doesn't affect the process as a whole, but only those windows created using it, it's perfectly possible to use the MBCS version in other parts of the same application. Therefore, even if an application using GLFW calls MBCS functions, there's no need for GLFW itself to support MBCS.
![[Main Page]](http://wiki.glfw.org/wiki/images/logo.png){kind=logo}