drinkingtea/nostalgia
2
0
Fork 0
Code Issues 4 Pull Requests Actions Releases 12 Activity

Merge commit '26c8cc348eacea01237cd64e1a68d0df8141e848'

Browse Source
This commit is contained in:
Gary Talent
2024-05-31 19:26:05 -05:00
parent fc25c12dbc 26c8cc348e
commit 1ecc7aa7aa
165 changed files with 33591 additions and 14989 deletions
Download Patch File Download Diff File Expand all files Collapse all files

71
deps/glfw/docs/CMakeLists.txt vendored
View File

@ -1,34 +1,57 @@
# NOTE: The order of this list determines the order of items in the Guides
# (i.e. Pages) list in the generated documentation
set(GLFW_DOXYGEN_SOURCES
"include/GLFW/glfw3.h"
"include/GLFW/glfw3native.h"
"docs/main.dox"
"docs/news.dox"
"docs/quick.dox"
"docs/moving.dox"
"docs/compile.dox"
"docs/build.dox"
"docs/intro.dox"
"docs/context.dox"
"docs/monitor.dox"
"docs/window.dox"
"docs/input.dox"
"docs/vulkan.dox"
"docs/compat.dox"
"docs/internal.dox")
set(source_files
main.md
news.md
quick.md
moving.md
compile.md
build.md
intro.md
context.md
monitor.md
window.md
input.md
vulkan.md
compat.md
internal.md)
set(extra_files DoxygenLayout.xml header.html footer.html extra.css spaces.svg)
set(header_paths
"${GLFW_SOURCE_DIR}/include/GLFW/glfw3.h"
"${GLFW_SOURCE_DIR}/include/GLFW/glfw3native.h")
# Format the source list into a Doxyfile INPUT value that Doxygen can parse
foreach(path IN LISTS GLFW_DOXYGEN_SOURCES)
set(GLFW_DOXYGEN_INPUT "${GLFW_DOXYGEN_INPUT} \\\n\"${GLFW_SOURCE_DIR}/${path}\"")
foreach(path IN LISTS header_paths)
string(APPEND GLFW_DOXYGEN_INPUT " \\\n\"${path}\"")
endforeach()
foreach(file IN LISTS source_files)
string(APPEND GLFW_DOXYGEN_INPUT " \\\n\"${CMAKE_CURRENT_SOURCE_DIR}/${file}\"")
endforeach()
configure_file(Doxyfile.in Doxyfile @ONLY)
set(DOXYGEN_SKIP_DOT TRUE)
find_package(Doxygen)
add_custom_target(docs ALL "${DOXYGEN_EXECUTABLE}"
WORKING_DIRECTORY "${GLFW_BINARY_DIR}/docs"
COMMENT "Generating HTML documentation" VERBATIM)
if (NOT DOXYGEN_FOUND OR DOXYGEN_VERSION VERSION_LESS "1.9.8")
message(STATUS "Documentation generation requires Doxygen 1.9.8 or later")
else()
configure_file(Doxyfile.in Doxyfile @ONLY)
add_custom_command(OUTPUT "html/index.html"
COMMAND "${DOXYGEN_EXECUTABLE}"
WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}"
MAIN_DEPENDENCY Doxyfile
DEPENDS ${header_paths} ${source_files} ${extra_files}
COMMENT "Generating HTML documentation"
VERBATIM)
set_target_properties(docs PROPERTIES FOLDER "GLFW3")
add_custom_target(docs ALL SOURCES "html/index.html")
set_target_properties(docs PROPERTIES FOLDER "GLFW3")
if (GLFW_INSTALL)
install(DIRECTORY "${GLFW_BINARY_DIR}/docs/html"
DESTINATION "${CMAKE_INSTALL_DOCDIR}")
endif()
endif()

10
deps/glfw/docs/CODEOWNERS vendored
View File

@ -1,10 +0,0 @@
* @elmindreda
src/wl_* @linkmauve
docs/*.css @glfw/webdev
docs/*.scss @glfw/webdev
docs/*.html @glfw/webdev
docs/*.xml @glfw/webdev

21
deps/glfw/docs/CONTRIBUTING.md vendored
View File

@ -23,13 +23,12 @@ Questions about how to use GLFW should be asked either in the [support
section](https://discourse.glfw.org/c/support) of the forum, under the [Stack
Overflow tag](https://stackoverflow.com/questions/tagged/glfw) or [Game
Development tag](https://gamedev.stackexchange.com/questions/tagged/glfw) on
Stack Exchange or in the IRC channel `#glfw` on
[Libera.Chat](https://libera.chat/).
Stack Exchange.
Questions about the design or implementation of GLFW or about future plans
should be asked in the [dev section](https://discourse.glfw.org/c/dev) of the
forum or in the IRC channel. Please don't open a GitHub issue to discuss design
questions without first checking with a maintainer.
forum. Please don't open a GitHub issue to discuss design questions without
first checking with a maintainer.
## Reporting a bug
@ -327,7 +326,7 @@ a thousand line one, if that is the appropriate size for the fix.
In addition to the code, a complete bug fix includes:
- Change log entry in `README.md`, describing the incorrect behavior
- Credits entries for all authors of the bug fix
- Credits entries in `CONTRIBUTORS.md` for all authors of the bug fix
Bug fixes will not be rejected because they don't include all the above parts,
but please keep in mind that maintainer time is finite and that there are many
@ -351,18 +350,18 @@ __Note:__ If you haven't already implemented the feature, check first if there
already is an open issue for it and if it's already being developed in an
[experimental branch](https://github.com/glfw/glfw/branches/all).
__There is no preferred patch size__. A one character change is just as welcome
as one adding a thousand line one, if that is the appropriate size for the
__There is no preferred patch size__. A one-character change is just as welcome
as one adding a thousand lines, if that is the appropriate size for the
feature.
In addition to the code, a complete feature includes:
- Change log entry in `README.md`, listing all new symbols
- News page entry, briefly describing the feature
- Guide documentation, with minimal examples, in the relevant guide
- News page entry in `docs/news.md`, briefly describing the feature
- Guide documentation, with minimal examples, in the relevant guide in the `docs` folder
- Reference documentation, with all applicable tags
- Cross-references and mentions in appropriate places
- Credits entries for all authors of the feature
- Credits entries in `CONTRIBUTORS.md` for all authors of the feature
If the feature requires platform-specific code, at minimum stubs must be added
for the new platform function to all supported and experimental platforms.
@ -374,7 +373,7 @@ If it adds a new monitor property, support for it must be added to
If it adds a new OpenGL, OpenGL ES or Vulkan option or extension, support
for it must be added to `tests/glfwinfo.c` and the behavior of the library when
the extension is missing documented in `docs/compat.dox`.
the extension is missing documented in `docs/compat.md`.
If you haven't already, read the excellent article [How to Write a Git Commit
Message](https://chris.beams.io/posts/git-commit/).

2789
deps/glfw/docs/Doxyfile.in vendored
View File

File diff suppressed because it is too large Load Diff

2
deps/glfw/docs/DoxygenLayout.xml vendored
View File

@ -5,7 +5,7 @@
<tab type="mainpage" visible="yes" title="Introduction"/>
<tab type="user" url="quick_guide.html" title="Tutorial"/>
<tab type="pages" visible="yes" title="Guides" intro=""/>
<tab type="modules" visible="yes" title="Reference" intro=""/>
<tab type="topics" visible="yes" title="Reference" intro=""/>
<tab type="filelist" visible="yes" title="Files"/>
</navindex>

3
deps/glfw/docs/SUPPORT.md vendored
View File

@ -4,8 +4,7 @@ See the [latest documentation](https://www.glfw.org/docs/latest/) for tutorials,
guides and the API reference.
If you have questions about using GLFW, we have a
[forum](https://discourse.glfw.org/), and the `#glfw` IRC channel on
[Libera.Chat](https://libera.chat/).
[forum](https://discourse.glfw.org/).
Bugs are reported to our [issue tracker](https://github.com/glfw/glfw/issues).
Please check the [contribution

253
deps/glfw/docs/build.dox → deps/glfw/docs/build.md vendored
View File

@ -1,8 +1,6 @@
/*!
# Building applications {#build_guide}
@page build_guide Building applications
@tableofcontents
[TOC]
This is about compiling and linking applications that use GLFW. For information on
how to write such applications, start with the
@ -16,17 +14,17 @@ and linking process should be explained in your C programming material and in
the documentation for your development environment.
@section build_include Including the GLFW header file
## Including the GLFW header file {#build_include}
You should include the GLFW header in the source files where you use OpenGL or
GLFW.
@code
```c
#include <GLFW/glfw3.h>
@endcode
```
This header defines all the constants and declares all the types and function
prototypes of the GLFW API. By default it also includes the OpenGL header from
prototypes of the GLFW API. By default, it also includes the OpenGL header from
your development environment. See [option macros](@ref build_macros) below for
how to select OpenGL ES headers and more.
@ -43,32 +41,33 @@ In other words:
- Do not include window system headers unless you will use those APIs directly
- If you do need such headers, include them before the GLFW header
If you are using an OpenGL extension loading library such as
[glad](https://github.com/Dav1dde/glad), the extension loader header should
be included before the GLFW one. GLFW attempts to detect any OpenGL or OpenGL
ES header or extension loader header included before it and will then disable
the inclusion of the default OpenGL header. Most extension loaders also define
macros that disable similar headers below it.
If you are using an OpenGL extension loading library such as [glad][], the
extension loader header should be included before the GLFW one. GLFW attempts
to detect any OpenGL or OpenGL ES header or extension loader header included
before it and will then disable the inclusion of the default OpenGL header.
Most extension loaders also define macros that disable similar headers below it.
@code
[glad]: https://github.com/Dav1dde/glad
```c
#include <glad/gl.h>
#include <GLFW/glfw3.h>
@endcode
```
Both of these mechanisms depend on the extension loader header defining a known
macro. If yours doesn't or you don't know which one your users will pick, the
@ref GLFW_INCLUDE_NONE macro will explicitly to prevent the GLFW header from
@ref GLFW_INCLUDE_NONE macro will explicitly prevent the GLFW header from
including the OpenGL header. This will also allow you to include the two
headers in any order.
@code
```c
#define GLFW_INCLUDE_NONE
#include <GLFW/glfw3.h>
#include <glad/gl.h>
@endcode
```
@subsection build_macros GLFW header option macros
### GLFW header option macros {#build_macros}
These macros may be defined before the inclusion of the GLFW header and affect
its behavior.
@ -82,8 +81,9 @@ Only one of these may be defined at a time.
@note GLFW does not provide any of the API headers mentioned below. They are
provided by your development environment or your OpenGL, OpenGL ES or Vulkan
SDK, and most of them can be downloaded from the
[Khronos Registry](https://www.khronos.org/registry/).
SDK, and most of them can be downloaded from the [Khronos Registry][registry].
[registry]: https://www.khronos.org/registry/
@anchor GLFW_INCLUDE_GLCOREARB
__GLFW_INCLUDE_GLCOREARB__ makes the GLFW header include the modern
@ -142,7 +142,7 @@ If your build includes GLFW and you define any these in your build files, make
sure they are not applied to the GLFW sources.
@section build_link Link with the right libraries
## Link with the right libraries {#build_link}
GLFW is essentially a wrapper of various platform-specific APIs and therefore
needs to link against many different system libraries. If you are using GLFW as
@ -155,28 +155,104 @@ hard-coded into your build environment. See the section for your development
environment below. On Linux and other Unix-like operating systems, the list
varies but can be retrieved in various ways as described below.
A good general introduction to linking is
[Beginner's Guide to Linkers](https://www.lurklurk.org/linkers/linkers.html) by
David Drysdale.
A good general introduction to linking is [Beginner's Guide to
Linkers][linker_guide] by David Drysdale.
[linker_guide]: https://www.lurklurk.org/linkers/linkers.html
@subsection build_link_win32 With MinGW or Visual C++ on Windows
### With Visual C++ and GLFW binaries {#build_link_win32}
The static version of the GLFW library is named `glfw3`. When using this
version, it is also necessary to link with some libraries that GLFW uses.
If you are using a downloaded [binary
archive](https://www.glfw.org/download.html), first make sure you have the
archive matching the architecture you are building for (32-bit or 64-bit), or
you will get link errors. Also make sure you are using the binaries for your
version of Visual C++ or you may get other link errors.
When using MinGW to link an application with the static version of GLFW, you
must also explicitly link with `gdi32`. Other toolchains including MinGW-w64
include it in the set of default libraries along with other dependencies like
`user32` and `kernel32`.
There are two version of the static GLFW library in the binary archive, because
it needs to use the same base run-time library variant as the rest of your
executable.
The link library for the GLFW DLL is named `glfw3dll`. When compiling an
application that uses the DLL version of GLFW, you need to define the @ref
GLFW_DLL macro _before_ any inclusion of the GLFW header. This can be done
either with a compiler switch or by defining it in your source code.
One is named `glfw3.lib` and is for projects with the _Runtime Library_ project
option set to _Multi-threaded DLL_ or _Multi-threaded Debug DLL_. The other is
named `glfw3_mt.lib` and is for projects with _Runtime Library_ set to
_Multi-threaded_ or _Multi-threaded Debug_. To use the static GLFW library you
will need to add `path/to/glfw3.lib` or `path/to/glfw3_mt.lib` to the
_Additional Dependencies_ project option.
If you compiled a GLFW static library yourself then there will only be one,
named `glfw3.lib`, and you have to make sure the run-time library variant
matches.
The DLL version of the GLFW library is named `glfw3.dll`, but you will be
linking against the `glfw3dll.lib` link library. To use the DLL you will need
to add `path/to/glfw3dll.lib` to the _Additional Dependencies_ project option.
All of its dependencies are already listed there by default, but when building
with the DLL version of GLFW, you also need to define the @ref GLFW_DLL. This
can be done either in the _Preprocessor Definitions_ project option or by
defining it in your source code before including the GLFW header.
```c
#define GLFW_DLL
#include <GLFW/glfw3.h>
```
All link-time dependencies for GLFW are already listed in the _Additional
Dependencies_ option by default.
@subsection build_link_cmake_source With CMake and GLFW source
### With MinGW-w64 and GLFW binaries {#build_link_mingw}
This is intended for building a program from the command-line or by writing
a makefile, on Windows with [MinGW-w64][] and GLFW binaries. These can be from
a downloaded and extracted [binary archive](https://www.glfw.org/download.html)
or by compiling GLFW yourself. The paths below assume a binary archive is used.
If you are using a downloaded binary archive, first make sure you have the
archive matching the architecture you are building for (32-bit or 64-bit) or you
will get link errors.
Note that the order of source files and libraries matter for GCC. Dependencies
must be listed after the files that depend on them. Any source files that
depend on GLFW must be listed before the GLFW library. GLFW in turn depends on
`gdi32` and must be listed before it.
[MinGW-w64]: https://www.mingw-w64.org/
If you are using the static version of the GLFW library, which is named
`libglfw3.a`, do:
```sh
gcc -o myprog myprog.c -I path/to/glfw/include path/to/glfw/lib-mingw-w64/libglfw3.a -lgdi32
```
If you are using the DLL version of the GLFW library, which is named
`glfw3.dll`, you will need to use the `libglfw3dll.a` link library.
```sh
gcc -o myprog myprog.c -I path/to/glfw/include path/to/glfw/lib-mingw-w64/libglfw3dll.a -lgdi32
```
The resulting executable will need to find `glfw3.dll` to run, typically by
keeping both files in the same directory.
When you are building with the DLL version of GLFW, you will also need to define
the @ref GLFW_DLL macro. This can be done in your source files, as long as it
done before including the GLFW header:
```c
#define GLFW_DLL
#include <GLFW/glfw3.h>
```
It can also be done on the command-line:
```sh
gcc -o myprog myprog.c -D GLFW_DLL -I path/to/glfw/include path/to/glfw/lib-mingw-w64/libglfw3dll.a -lgdi32
```
### With CMake and GLFW source {#build_link_cmake_source}
This section is about using CMake to compile and link GLFW along with your
application. If you want to use an installed binary instead, see @ref
@ -185,31 +261,21 @@ build_link_cmake_package.
With a few changes to your `CMakeLists.txt` you can have the GLFW source tree
built along with your application.
When including GLFW as part of your build, you probably don't want to build the
GLFW tests, examples and documentation. To disable these, set the corresponding
cache variables before adding the GLFW source tree.
@code
set(GLFW_BUILD_DOCS OFF CACHE BOOL "" FORCE)
set(GLFW_BUILD_TESTS OFF CACHE BOOL "" FORCE)
set(GLFW_BUILD_EXAMPLES OFF CACHE BOOL "" FORCE)
@endcode
Add the root directory of the GLFW source tree to your project. This will add
the `glfw` target to your project.
@code{.cmake}
```cmake
add_subdirectory(path/to/glfw)
@endcode
```
Once GLFW has been added, link your application against the `glfw` target.
This adds the GLFW library and its link-time dependencies as it is currently
configured, the include directory for the GLFW header and, when applicable, the
@ref GLFW_DLL macro.
@code{.cmake}
```cmake
target_link_libraries(myapp glfw)
@endcode
```
Note that the `glfw` target does not depend on OpenGL, as GLFW loads any OpenGL,
OpenGL ES or Vulkan libraries it needs at runtime. If your application calls
@ -217,22 +283,24 @@ OpenGL directly, instead of using a modern
[extension loader library](@ref context_glext_auto), use the OpenGL CMake
package.
@code{.cmake}
```cmake
find_package(OpenGL REQUIRED)
@endcode
```
If OpenGL is found, the `OpenGL::GL` target is added to your project, containing
library and include directory paths. Link against this like any other library.
@code{.cmake}
```cmake
target_link_libraries(myapp OpenGL::GL)
@endcode
```
For a minimal example of a program and GLFW sources built with CMake, see the
[GLFW CMake Starter](https://github.com/juliettef/GLFW-CMake-starter) on GitHub.
[GLFW CMake Starter][cmake_starter] on GitHub.
[cmake_starter]: https://github.com/juliettef/GLFW-CMake-starter
@subsection build_link_cmake_package With CMake and installed GLFW binaries
### With CMake and installed GLFW binaries {#build_link_cmake_package}
This section is about using CMake to link GLFW after it has been built and
installed. If you want to build it along with your application instead, see
@ -241,17 +309,17 @@ installed. If you want to build it along with your application instead, see
With a few changes to your `CMakeLists.txt` you can locate the package and
target files generated when GLFW is installed.
@code{.cmake}
find_package(glfw3 3.3 REQUIRED)
@endcode
```cmake
find_package(glfw3 3.4 REQUIRED)
```
Once GLFW has been added to the project, link against it with the `glfw` target.
This adds the GLFW library and its link-time dependencies, the include directory
for the GLFW header and, when applicable, the @ref GLFW_DLL macro.
@code{.cmake}
```cmake
target_link_libraries(myapp glfw)
@endcode
```
Note that the `glfw` target does not depend on OpenGL, as GLFW loads any OpenGL,
OpenGL ES or Vulkan libraries it needs at runtime. If your application calls
@ -259,47 +327,51 @@ OpenGL directly, instead of using a modern
[extension loader library](@ref context_glext_auto), use the OpenGL CMake
package.
@code{.cmake}
```cmake
find_package(OpenGL REQUIRED)
@endcode
```
If OpenGL is found, the `OpenGL::GL` target is added to your project, containing
library and include directory paths. Link against this like any other library.
@code{.cmake}
```cmake
target_link_libraries(myapp OpenGL::GL)
@endcode
```
@subsection build_link_pkgconfig With makefiles and pkg-config on Unix
### With pkg-config and GLFW binaries on Unix {#build_link_pkgconfig}
GLFW supports [pkg-config](https://www.freedesktop.org/wiki/Software/pkg-config/),
and the `glfw3.pc` pkg-config file is generated when the GLFW library is built
and is installed along with it. A pkg-config file describes all necessary
compile-time and link-time flags and dependencies needed to use a library. When
they are updated or if they differ between systems, you will get the correct
ones automatically.
This is intended for building a program from the command-line or by writing
a makefile, on macOS or any Unix-like system like Linux, FreeBSD and Cygwin.
GLFW supports [pkg-config][], and the `glfw3.pc` pkg-config file is generated
when the GLFW library is built and is installed along with it. A pkg-config
file describes all necessary compile-time and link-time flags and dependencies
needed to use a library. When they are updated or if they differ between
systems, you will get the correct ones automatically.
[pkg-config]: https://www.freedesktop.org/wiki/Software/pkg-config/
A typical compile and link command-line when using the static version of the
GLFW library may look like this:
@code{.sh}
```sh
cc $(pkg-config --cflags glfw3) -o myprog myprog.c $(pkg-config --static --libs glfw3)
@endcode
```
If you are using the shared version of the GLFW library, omit the `--static`
flag.
@code{.sh}
```sh
cc $(pkg-config --cflags glfw3) -o myprog myprog.c $(pkg-config --libs glfw3)
@endcode
```
You can also use the `glfw3.pc` file without installing it first, by using the
`PKG_CONFIG_PATH` environment variable.
@code{.sh}
```sh
env PKG_CONFIG_PATH=path/to/glfw/src cc $(pkg-config --cflags glfw3) -o myprog myprog.c $(pkg-config --libs glfw3)
@endcode
```
The dependencies do not include OpenGL, as GLFW loads any OpenGL, OpenGL ES or
Vulkan libraries it needs at runtime. If your application calls OpenGL
@ -307,12 +379,12 @@ directly, instead of using a modern
[extension loader library](@ref context_glext_auto), you should add the `gl`
pkg-config package.
@code{.sh}
```sh
cc $(pkg-config --cflags glfw3 gl) -o myprog myprog.c $(pkg-config --libs glfw3 gl)
@endcode
```
@subsection build_link_xcode With Xcode on macOS
### With Xcode on macOS {#build_link_xcode}
If you are using the dynamic library version of GLFW, add it to the project
dependencies.
@ -322,19 +394,19 @@ OpenGL and IOKit frameworks to the project as dependencies. They can all be
found in `/System/Library/Frameworks`.
@subsection build_link_osx With command-line on macOS
### With command-line or makefile on macOS {#build_link_osx}
It is recommended that you use [pkg-config](@ref build_link_pkgconfig) when
building from the command line on macOS. That way you will get any new
dependencies added automatically. If you still wish to build manually, you need
to add the required frameworks and libraries to your command-line yourself using
the `-l` and `-framework` switches.
using installed GLFW binaries from the command line on macOS. That way you will
get any new dependencies added automatically. If you still wish to build
manually, you need to add the required frameworks and libraries to your
command-line yourself using the `-l` and `-framework` switches.
If you are using the dynamic GLFW library, which is named `libglfw.3.dylib`, do:
@code{.sh}
```sh
cc -o myprog myprog.c -lglfw -framework Cocoa -framework OpenGL -framework IOKit
@endcode
```
If you are using the static library, named `libglfw3.a`, substitute `-lglfw3`
for `-lglfw`.
@ -345,4 +417,3 @@ against it from the command-line.
@note Your machine may have `libGL.*.dylib` style OpenGL library, but that is
for the X Window System and will not work with the macOS native version of GLFW.
*/

187
deps/glfw/docs/compat.dox → deps/glfw/docs/compat.md vendored
View File

@ -1,8 +1,6 @@
/*!
# Standards conformance {#compat_guide}
@page compat_guide Standards conformance
@tableofcontents
[TOC]
This guide describes the various API extensions used by this version of GLFW.
It lists what are essentially implementation details, but which are nonetheless
@ -15,18 +13,18 @@ part of this information may change in future versions of GLFW and that will not
be considered a breaking API change.
@section compat_x11 X11 extensions, protocols and IPC standards
## X11 extensions, protocols and IPC standards {#compat_x11}
As GLFW uses Xlib directly, without any intervening toolkit
library, it has sole responsibility for interacting well with the many and
varied window managers in use on Unix-like systems. In order for applications
and window managers to work well together, a number of standards and
conventions have been developed that regulate behavior outside the scope of the
X11 API; most importantly the
[Inter-Client Communication Conventions Manual](https://www.tronche.com/gui/x/icccm/)
(ICCCM) and
[Extended Window Manager Hints](https://standards.freedesktop.org/wm-spec/wm-spec-latest.html)
(EWMH) standards.
As GLFW uses Xlib directly, without any intervening toolkit library, it has sole
responsibility for interacting well with the many and varied window managers in
use on Unix-like systems. In order for applications and window managers to work
well together, a number of standards and conventions have been developed that
regulate behavior outside the scope of the X11 API; most importantly the
[Inter-Client Communication Conventions Manual][ICCCM] (ICCCM) and [Extended
Window Manager Hints][EWMH] (EWMH) standards.
[ICCCM]: https://www.tronche.com/gui/x/icccm/
[EWMH]: https://standards.freedesktop.org/wm-spec/wm-spec-latest.html
GLFW uses the `_MOTIF_WM_HINTS` window property to support borderless windows.
If the running window manager does not support this property, the
@ -52,16 +50,18 @@ compositing window manager to un-redirect full screen GLFW windows. If the
running window manager uses compositing but does not support this property then
additional copying may be performed for each buffer swap of full screen windows.
GLFW uses the
[clipboard manager protocol](https://www.freedesktop.org/wiki/ClipboardManager/)
to push a clipboard string (i.e. selection) owned by a GLFW window about to be
destroyed to the clipboard manager. If there is no running clipboard manager,
the clipboard string will be unavailable once the window has been destroyed.
GLFW uses the [clipboard manager protocol][ClipboardManager] to push a clipboard
string (i.e. selection) owned by a GLFW window about to be destroyed to the
clipboard manager. If there is no running clipboard manager, the clipboard
string will be unavailable once the window has been destroyed.
GLFW uses the
[X drag-and-drop protocol](https://www.freedesktop.org/wiki/Specifications/XDND/)
to provide file drop events. If the application originating the drag does not
support this protocol, drag and drop will not work.
[clipboardManager]: https://www.freedesktop.org/wiki/ClipboardManager/
GLFW uses the [X drag-and-drop protocol][XDND] to provide file drop events. If
the application originating the drag does not support this protocol, drag and
drop will not work.
[XDND]: https://www.freedesktop.org/wiki/Specifications/XDND/
GLFW uses the XRandR 1.3 extension to provide multi-monitor support. If the
running X server does not support this version of this extension, multi-monitor
@ -85,62 +85,81 @@ transparent window framebuffers. If the running X server does not support this
extension or there is no running compositing manager, the
`GLFW_TRANSPARENT_FRAMEBUFFER` framebuffer hint will have no effect.
GLFW uses both the Xcursor extension and the freedesktop cursor conventions to
provide an expanded set of standard cursor shapes. If the running X server does
not support this extension or the current cursor theme does not support the
conventions, the `GLFW_RESIZE_NWSE_CURSOR`, `GLFW_RESIZE_NESW_CURSOR` and
`GLFW_NOT_ALLOWED_CURSOR` shapes will not be available and other shapes may use
legacy images.
@section compat_wayland Wayland protocols and IPC standards
## Wayland protocols and IPC standards {#compat_wayland}
As GLFW uses libwayland directly, without any intervening toolkit library, it
has sole responsibility for interacting well with every compositor in use on
Unix-like systems. Most of the features are provided by the core protocol,
while cursor support is provided by the libwayland-cursor helper library, EGL
integration by libwayland-egl, and keyboard handling by
[libxkbcommon](https://xkbcommon.org/). In addition, GLFW uses some protocols
from wayland-protocols to provide additional features if the compositor
supports them.
[libxkbcommon](https://xkbcommon.org/). In addition, GLFW uses some additional
Wayland protocols to implement certain features if the compositor supports them.
GLFW uses xkbcommon 0.5.0 to provide compose key support. When it has been
built against an older xkbcommon, the compose key will be disabled even if it
has been configured in the compositor.
GLFW uses xkbcommon 0.5.0 to provide key and text input support. Earlier
versions are not supported.
GLFW uses the [xdg-shell
protocol](https://cgit.freedesktop.org/wayland/wayland-protocols/tree/stable/xdg-shell/xdg-shell.xml)
to provide better window management. This protocol is part of
wayland-protocols 1.12, and mandatory at build time. If the running compositor
does not support this protocol, the older [wl_shell
interface](https://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml#n972)
will be used instead. This will result in a worse integration with the
desktop, especially on tiling compositors.
GLFW uses the [xdg-shell][] protocol to provide better window management. This
protocol is mandatory for GLFW to display a window.
GLFW uses the [relative pointer
protocol](https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/relative-pointer/relative-pointer-unstable-v1.xml)
alongside the [pointer constraints
protocol](https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml)
to implement disabled cursor. These two protocols are part of
wayland-protocols 1.1, and mandatory at build time. If the running compositor
does not support both of these protocols, disabling the cursor will have no
effect.
[xdg-shell]: https://wayland.app/protocols/xdg-shell
GLFW uses the [idle inhibit
protocol](https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml)
to prohibit the screensaver from starting. This protocol is part of
wayland-protocols 1.6, and mandatory at build time. If the running compositor
does not support this protocol, the screensaver may start even for full screen
windows.
GLFW uses the [relative-pointer-unstable-v1][] protocol alongside the
[pointer-constraints-unstable-v1][] protocol to implement disabled cursor. If
the running compositor does not support both of these protocols, disabling the
cursor will have no effect.
GLFW uses the [xdg-decoration
protocol](https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml)
to request decorations to be drawn around its windows. This protocol is part
of wayland-protocols 1.15, and mandatory at build time. If the running
compositor does not support this protocol, a very simple frame will be drawn by
GLFW itself, using the [viewporter
protocol](https://cgit.freedesktop.org/wayland/wayland-protocols/tree/stable/viewporter/viewporter.xml)
alongside
[subsurfaces](https://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml#n2598).
This protocol is part of wayland-protocols 1.4, and mandatory at build time.
If the running compositor does not support this protocol either, no decorations
will be drawn around windows.
[relative-pointer-unstable-v1]: https://wayland.app/protocols/relative-pointer-unstable-v1
[pointer-constraints-unstable-v1]: https://wayland.app/protocols/pointer-constraints-unstable-v1
GLFW uses the [idle-inhibit-unstable-v1][] protocol to prohibit the screensaver
from starting. If the running compositor does not support this protocol, the
screensaver may start even for full screen windows.
[idle-inhibit-unstable-v1]: https://wayland.app/protocols/idle-inhibit-unstable-v1
GLFW uses the [libdecor][] library for window decorations, where available.
This in turn provides good quality client-side decorations (drawn by the
application) on desktop systems that do not support server-side decorations
(drawn by the window manager). On systems that do not provide either libdecor
or xdg-decoration, very basic window decorations are provided. These do not
include the window title or any caption buttons.
[libdecor]: https://gitlab.freedesktop.org/libdecor/libdecor
GLFW uses the [xdg-decoration-unstable-v1][] protocol to request decorations to
be drawn around its windows. This protocol is part of wayland-protocols 1.15,
and mandatory at build time. If the running compositor does not support this
protocol, a very simple frame will be drawn by GLFW itself, using the
[viewporter][] protocol alongside subsurfaces. If the running compositor does
not support these protocols either, no decorations will be drawn around windows.
[xdg-decoration-unstable-v1]: https://wayland.app/protocols/xdg-decoration-unstable-v1
[viewporter]: https://wayland.app/protocols/viewporter
GLFW uses the [xdg-activation-v1][] protocol to implement window focus and
attention requests. If the running compositor does not support this protocol,
window focus and attention requests do nothing.
[xdg-activation-v1]: https://wayland.app/protocols/xdg-activation-v1
GLFW uses the [fractional-scale-v1][] protocol to implement fine-grained
framebuffer scaling. If the running compositor does not support this protocol,
the @ref GLFW_SCALE_FRAMEBUFFER window hint will only be able to scale the
framebuffer by integer scales. This will typically be the smallest integer not
less than the actual scale.
[fractional-scale-v1]: https://wayland.app/protocols/fractional-scale-v1
@section compat_glx GLX extensions
## GLX extensions {#compat_glx}
The GLX API is the default API used to create OpenGL contexts on Unix-like
systems using the X Window System.
@ -150,7 +169,7 @@ formats. If GLX 1.3 is not supported, @ref glfwInit will fail.
GLFW uses the `GLX_MESA_swap_control,` `GLX_EXT_swap_control` and
`GLX_SGI_swap_control` extensions to provide vertical retrace synchronization
(or _vsync_), in that order of preference. Where none of these extension are
(or _vsync_), in that order of preference. When none of these extensions are
available, calling @ref glfwSwapInterval will have no effect.
GLFW uses the `GLX_ARB_multisample` extension to create contexts with
@ -160,10 +179,9 @@ multisampling anti-aliasing. Where this extension is unavailable, the
GLFW uses the `GLX_ARB_create_context` extension when available, even when
creating OpenGL contexts of version 2.1 and below. Where this extension is
unavailable, the `GLFW_CONTEXT_VERSION_MAJOR` and `GLFW_CONTEXT_VERSION_MINOR`
hints will only be partially supported, the `GLFW_OPENGL_DEBUG_CONTEXT` hint
will have no effect, and setting the `GLFW_OPENGL_PROFILE` or
`GLFW_OPENGL_FORWARD_COMPAT` hints to `GLFW_TRUE` will cause @ref
glfwCreateWindow to fail.
hints will only be partially supported, the `GLFW_CONTEXT_DEBUG` hint will have
no effect, and setting the `GLFW_OPENGL_PROFILE` or `GLFW_OPENGL_FORWARD_COMPAT`
hints to `GLFW_TRUE` will cause @ref glfwCreateWindow to fail.
GLFW uses the `GLX_ARB_create_context_profile` extension to provide support for
context profiles. Where this extension is unavailable, setting the
@ -181,7 +199,7 @@ extensions to provide support for sRGB framebuffers. Where both of these
extensions are unavailable, the `GLFW_SRGB_CAPABLE` hint will have no effect.
@section compat_wgl WGL extensions
## WGL extensions {#compat_wgl}
The WGL API is used to create OpenGL contexts on Microsoft Windows and other
implementations of the Win32 API, such as Wine.
@ -203,10 +221,9 @@ unavailable, the `GLFW_SAMPLES` hint will have no effect.
GLFW uses the `WGL_ARB_create_context` extension when available, even when
creating OpenGL contexts of version 2.1 and below. Where this extension is
unavailable, the `GLFW_CONTEXT_VERSION_MAJOR` and `GLFW_CONTEXT_VERSION_MINOR`
hints will only be partially supported, the `GLFW_OPENGL_DEBUG_CONTEXT` hint
will have no effect, and setting the `GLFW_OPENGL_PROFILE` or
`GLFW_OPENGL_FORWARD_COMPAT` hints to `GLFW_TRUE` will cause @ref
glfwCreateWindow to fail.
hints will only be partially supported, the `GLFW_CONTEXT_DEBUG` hint will have
no effect, and setting the `GLFW_OPENGL_PROFILE` or `GLFW_OPENGL_FORWARD_COMPAT`
hints to `GLFW_TRUE` will cause @ref glfwCreateWindow to fail.
GLFW uses the `WGL_ARB_create_context_profile` extension to provide support for
context profiles. Where this extension is unavailable, setting the
@ -219,11 +236,11 @@ extension is unavailable, the `GLFW_CONTEXT_RELEASE_BEHAVIOR` hint will have no
effect and the context will always be flushed when released.
GLFW uses the `WGL_ARB_framebuffer_sRGB` and `WGL_EXT_framebuffer_sRGB`
extensions to provide support for sRGB framebuffers. Where both of these
extension are unavailable, the `GLFW_SRGB_CAPABLE` hint will have no effect.
extensions to provide support for sRGB framebuffers. When both of these
extensions are unavailable, the `GLFW_SRGB_CAPABLE` hint will have no effect.
@section compat_osx OpenGL on macOS
## OpenGL on macOS {#compat_osx}
Support for OpenGL 3.2 and above was introduced with OS X 10.7 and even then
only forward-compatible, core profile contexts are supported. Support for
@ -234,19 +251,18 @@ at most OpenGL version 2.1.
Because of this, on OS X 10.7 and later, the `GLFW_CONTEXT_VERSION_MAJOR` and
`GLFW_CONTEXT_VERSION_MINOR` hints will cause @ref glfwCreateWindow to fail if
given version 3.0 or 3.1. The `GLFW_OPENGL_FORWARD_COMPAT` hint must be set to
`GLFW_TRUE` and the `GLFW_OPENGL_PROFILE` hint must be set to
given version 3.0 or 3.1. The `GLFW_OPENGL_PROFILE` hint must be set to
`GLFW_OPENGL_CORE_PROFILE` when creating OpenGL 3.2 and later contexts. The
`GLFW_OPENGL_DEBUG_CONTEXT` and `GLFW_CONTEXT_NO_ERROR` hints are ignored.
`GLFW_CONTEXT_DEBUG` and `GLFW_CONTEXT_NO_ERROR` hints are ignored.
Also, on Mac OS X 10.6 and below, the `GLFW_CONTEXT_VERSION_MAJOR` and
`GLFW_CONTEXT_VERSION_MINOR` hints will fail if given a version above 2.1,
setting the `GLFW_OPENGL_PROFILE` or `GLFW_OPENGL_FORWARD_COMPAT` hints to
a non-default value will cause @ref glfwCreateWindow to fail and the
`GLFW_OPENGL_DEBUG_CONTEXT` hint is ignored.
`GLFW_CONTEXT_DEBUG` hint is ignored.
@section compat_vulkan Vulkan loader and API
## Vulkan loader and API {#compat_vulkan}
By default, GLFW uses the standard system-wide Vulkan loader to access the
Vulkan API on all platforms except macOS. This is installed by both graphics
@ -256,7 +272,7 @@ all other Vulkan-related functions will fail with an @ref GLFW_API_UNAVAILABLE
error.
@section compat_wsi Vulkan WSI extensions
## Vulkan WSI extensions {#compat_wsi}
The Vulkan WSI extensions are used to create Vulkan surfaces for GLFW windows on
all supported platforms.
@ -282,4 +298,3 @@ surfaces on Wayland. If any of these extensions are not available, @ref
glfwGetRequiredInstanceExtensions will return an empty list and window surface
creation will fail.
*/

280
deps/glfw/docs/compile.dox → deps/glfw/docs/compile.md vendored
View File

@ -1,17 +1,17 @@
/*!
# Compiling GLFW {#compile_guide}
@page compile_guide Compiling GLFW
@tableofcontents
[TOC]
This is about compiling the GLFW library itself. For information on how to
build applications that use GLFW, see @ref build_guide.
GLFW uses some C99 features and does not support Visual Studio 2012 and earlier.
@section compile_cmake Using CMake
@note GLFW behaves like most other libraries that use CMake so this guide mostly
describes the basic configure/generate/compile sequence. If you are already
## Using CMake {#compile_cmake}
GLFW behaves like most other libraries that use CMake so this guide mostly
describes the standard configure, generate and compile sequence. If you are already
familiar with this from other projects, you may want to focus on the @ref
compile_deps and @ref compile_options sections for GLFW-specific information.
@ -19,8 +19,8 @@ GLFW uses [CMake](https://cmake.org/) to generate project files or makefiles
for your chosen development environment. To compile GLFW, first generate these
files with CMake and then use them to compile the GLFW library.
If you are on Windows and macOS you can
[download CMake](https://cmake.org/download/) from their site.
If you are on Windows and macOS you can [download
CMake](https://cmake.org/download/) from their site.
If you are on a Unix-like system such as Linux, FreeBSD or Cygwin or have
a package system like Fink, MacPorts or Homebrew, you can install its CMake
@ -28,83 +28,65 @@ package.
CMake is a complex tool and this guide will only show a few of the possible ways
to set up and compile GLFW. The CMake project has their own much more detailed
[CMake user guide](https://cmake.org/cmake/help/latest/guide/user-interaction/)
that includes everything in this guide not specific to GLFW. It may be a useful
companion to this one.
[CMake user guide][cmake-guide] that includes everything in this guide not
specific to GLFW. It may be a useful companion to this one.
[cmake-guide]: https://cmake.org/cmake/help/latest/guide/user-interaction/
@subsection compile_deps Installing dependencies
### Installing dependencies {#compile_deps}
The C/C++ development environments in Visual Studio, Xcode and MinGW come with
all necessary dependencies for compiling GLFW, but on Unix-like systems like
Linux and FreeBSD you will need a few extra packages.
@subsubsection compile_deps_x11 Dependencies for X11 on Unix-like systems
#### Dependencies for Wayland and X11 {#compile_deps_wayland}
To compile GLFW for X11, you need to have the X11 development packages
installed. They are not needed to build or run programs that use GLFW.
By default, both the Wayland and X11 backends are enabled on Linux and other Unix-like
systems (except macOS). To disable one or both of these, set the @ref GLFW_BUILD_WAYLAND
or @ref GLFW_BUILD_X11 CMake options in the next step when generating build files.
On Debian and derivates like Ubuntu and Linux Mint the `xorg-dev` meta-package
pulls in the development packages for all of X11.
To compile GLFW for both Wayland and X11, you need to have the X11, Wayland and xkbcommon
development packages installed. On some systems a few other packages are also required.
None of the development packages above are needed to build or run programs that use an
already compiled GLFW library.
@code{.sh}
sudo apt install xorg-dev
@endcode
On Debian and derivatives like Ubuntu and Linux Mint you will need the `libwayland-dev`
and `libxkbcommon-dev` packages to compile for Wayland and the `xorg-dev` meta-package to
compile for X11. These will pull in all other dependencies.
On Fedora and derivatives like Red Hat the X11 extension packages
`libXcursor-devel`, `libXi-devel`, `libXinerama-devel` and `libXrandr-devel`
required by GLFW pull in all its other dependencies.
```sh
sudo apt install libwayland-dev libxkbcommon-dev xorg-dev
```
@code{.sh}
sudo dnf install libXcursor-devel libXi-devel libXinerama-devel libXrandr-devel
@endcode
On Fedora and derivatives like Red Hat you will need the `wayland-devel` and
`libxkbcommon-devel` packages to compile for Wayland and the `libXcursor-devel`,
`libXi-devel`, `libXinerama-devel` and `libXrandr-devel` packages to compile for X11.
These will pull in all other dependencies.
On FreeBSD the X11 headers are installed along the end-user X11 packages, so if
you have an X server running you should have the headers as well. If not,
install the `xorgproto` package.
```sh
sudo dnf install wayland-devel libxkbcommon-devel libXcursor-devel libXi-devel libXinerama-devel libXrandr-devel
```
@code{.sh}
pkg install xorgproto
@endcode
On FreeBSD you will need the `wayland`, `libxkbcommon` and `evdev-proto` packages to
compile for Wayland. The X11 headers are installed along the end-user X11 packages, so if
you have an X server running you should have the headers as well. If not, install the
`xorgproto` package to compile for X11.
On Cygwin the `xorgproto` package in the Devel section of the GUI installer will
install the headers and other development related files for all of X11.
```sh
pkg install wayland libxkbcommon evdev-proto xorgproto
```
Once you have the required depdendencies, move on to @ref compile_generate.
On Cygwin Wayland is not supported but you will need the `libXcursor-devel`,
`libXi-devel`, `libXinerama-devel`, `libXrandr-devel` and `libXrender-devel` packages to
compile for X11. These can be found in the Libs section of the GUI installer and will
pull in all other dependencies.
Once you have the required dependencies, move on to @ref compile_generate.
@subsubsection compile_deps_wayland Dependencies for Wayland on Unix-like systems
To compile GLFW for Wayland, you need to have the Wayland and xkbcommon
development packages installed. They are not needed to build or run programs
that use GLFW.
On Debian and derivates like Ubuntu and Linux Mint you will need the `libwayland-dev`,
`libxkbcommon-dev`, `wayland-protocols` and `extra-cmake-modules` packages.
@code{.sh}
sudo apt install libwayland-dev libxkbcommon-dev wayland-protocols extra-cmake-modules
@endcode
On Fedora and derivatives like Red Hat you will need the `wayland-devel`,
`libxkbcommon-devel`, `wayland-protocols-devel` and `extra-cmake-modules` packages.
@code{.sh}
sudo dnf install wayland-devel libxkbcommon-devel wayland-protocols-devel extra-cmake-modules
@endcode
On FreeBSD you will need the `wayland`, `libxkbcommon`, `wayland-protocols` and
`kf5-extra-cmake-modules` packages.
@code{.sh}
pkg install wayland libxkbcommon wayland-protocols kf5-extra-cmake-modules
@endcode
Once you have the required depdendencies, move on to @ref compile_generate.
@subsection compile_generate Generating build files with CMake
### Generating build files with CMake {#compile_generate}
Once you have all necessary dependencies it is time to generate the project
files or makefiles for your development environment. CMake needs two paths for
@ -126,7 +108,7 @@ A common pattern when building a single configuration is to have a build
directory named `build` in the root of the source tree.
@subsubsection compile_generate_gui Generating files with the CMake GUI
#### Generating with the CMake GUI {#compile_generate_gui}
Start the CMake GUI and set the paths to the source and build directories
described above. Then press _Configure_ and _Generate_.
@ -135,52 +117,54 @@ If you wish change any CMake variables in the list, press _Configure_ and then
_Generate_ to have the new values take effect. The variable list will be
populated after the first configure step.
By default GLFW will use X11 on Linux and other Unix-like systems other
than macOS. To use Wayland instead, set the `GLFW_USE_WAYLAND` option in the
GLFW section of the variable list, then apply the new value as described above.
By default, GLFW will use Wayland and X11 on Linux and other Unix-like systems other than
macOS. To disable support for one or both of these, set the @ref GLFW_BUILD_WAYLAND
and/or @ref GLFW_BUILD_X11 option in the GLFW section of the variable list, then apply the
new value as described above.
Once you have generated the project files or makefiles for your chosen
development environment, move on to @ref compile_compile.
@subsubsection compile_generate_cli Generating files with the CMake command-line tool
#### Generating with command-line CMake {#compile_generate_cli}
To make a build directory, pass the source and build directories to the `cmake`
command. These can be relative or absolute paths. The build directory is
created if it doesn't already exist.
@code{.sh}
```sh
cmake -S path/to/glfw -B path/to/build
@endcode
```
It is common to name the build directory `build` and place it in the root of the
source tree when only planning to build a single configuration.
@code{.sh}
```sh
cd path/to/glfw
cmake -S . -B build
@endcode
```
Without other flags these will generate Visual Studio project files on Windows
and makefiles on other platforms. You can choose other targets using the `-G`
flag.
@code{.sh}
```sh
cmake -S path/to/glfw -B path/to/build -G Xcode
@endcode
```
By default GLFW will use X11 on Linux and other Unix-like systems other
than macOS. To use Wayland instead, set the `GLFW_USE_WAYLAND` CMake option.
By default, GLFW will use Wayland and X11 on Linux and other Unix-like systems other than
macOS. To disable support for one or both of these, set the @ref GLFW_BUILD_WAYLAND
and/or @ref GLFW_BUILD_X11 CMake option.
@code{.sh}
cmake -S path/to/glfw -B path/to/build -D GLFW_USE_WAYLAND=1
@endcode
```sh
cmake -S path/to/glfw -B path/to/build -D GLFW_BUILD_X11=0
```
Once you have generated the project files or makefiles for your chosen
development environment, move on to @ref compile_compile.
@subsection compile_compile Compiling the library
### Compiling the library {#compile_compile}
You should now have all required dependencies and the project files or makefiles
necessary to compile GLFW. Go ahead and compile the actual GLFW library with
@ -191,24 +175,24 @@ With Visual Studio open `GLFW.sln` and use the Build menu. With Xcode open
With Linux, macOS and other forms of Unix, run `make`.
@code{.sh}
```sh
cd path/to/build
make
@endcode
```
With MinGW, it is `mingw32-make`.
@code{.sh}
```sh
cd path/to/build
mingw32-make
@endcode
```
Any CMake build directory can also be built with the `cmake` command and the
`--build` flag.
@code{.sh}
```sh
cmake --build path/to/build
@endcode
```
This will run the platform specific build tool the directory was generated for.
@ -216,7 +200,7 @@ Once the GLFW library is compiled you are ready to build your application,
linking it to the GLFW library. See @ref build_guide for more information.
@section compile_options CMake options
## CMake options {#compile_options}
The CMake files for GLFW provide a number of options, although not all are
available on all supported platforms. Some of these are de facto standards
@ -231,47 +215,60 @@ distributions based on Debian GNU/Linux have this tool in a separate
Finally, if you don't want to use any GUI, you can set options from the `cmake`
command-line with the `-D` flag.
@code{.sh}
```sh
cmake -S path/to/glfw -B path/to/build -D BUILD_SHARED_LIBS=ON
@endcode
```
@subsection compile_options_shared Shared CMake options
### Shared CMake options {#compile_options_shared}
@anchor BUILD_SHARED_LIBS
__BUILD_SHARED_LIBS__ determines whether GLFW is built as a static
library or as a DLL / shared library / dynamic library. This is disabled by
default, producing a static GLFW library.
__BUILD_SHARED_LIBS__ determines whether GLFW is built as a static library or as
a DLL / shared library / dynamic library. This is disabled by default,
producing a static GLFW library. This variable has no `GLFW_` prefix because it
is defined by CMake. If you want to change the library only for GLFW when it is
part of a larger project, see @ref GLFW_LIBRARY_TYPE.
@anchor GLFW_LIBRARY_TYPE
__GLFW_LIBRARY_TYPE__ allows you to override @ref BUILD_SHARED_LIBS only for
GLFW, without affecting other libraries in a larger project. When set, the
value of this option must be a valid CMake library type. Set it to `STATIC` to
build GLFW as a static library, `SHARED` to build it as a shared library
/ dynamic library / DLL, or `OBJECT` to make GLFW a CMake object library.
@anchor GLFW_BUILD_EXAMPLES
__GLFW_BUILD_EXAMPLES__ determines whether the GLFW examples are built
along with the library.
along with the library. This is enabled by default unless GLFW is being built
as a subproject of a larger CMake project.
@anchor GLFW_BUILD_TESTS
__GLFW_BUILD_TESTS__ determines whether the GLFW test programs are
built along with the library.
built along with the library. This is enabled by default unless GLFW is being
built as a subproject of a larger CMake project.
@anchor GLFW_BUILD_DOCS
__GLFW_BUILD_DOCS__ determines whether the GLFW documentation is built along
with the library. This is enabled by default if
[Doxygen](https://www.doxygen.nl/) is found by CMake during configuration.
@anchor GLFW_VULKAN_STATIC
__GLFW_VULKAN_STATIC__ determines whether to use the Vulkan loader linked
directly with the application. This is disabled by default.
### Win32 specific CMake options {#compile_options_win32}
@subsection compile_options_win32 Windows specific CMake options
@anchor GLFW_BUILD_WIN32
__GLFW_BUILD_WIN32__ determines whether to include support for Win32 when compiling the
library. This option is only available when compiling for Windows. This is enabled by
default.
@anchor USE_MSVC_RUNTIME_LIBRARY_DLL
__USE_MSVC_RUNTIME_LIBRARY_DLL__ determines whether to use the DLL version or the
static library version of the Visual C++ runtime library. When enabled, the
DLL version of the Visual C++ library is used. This is enabled by default.
On CMake 3.15 and later you can set the standard CMake
[CMAKE_MSVC_RUNTIME_LIBRARY](https://cmake.org/cmake/help/latest/variable/CMAKE_MSVC_RUNTIME_LIBRARY.html)
On CMake 3.15 and later you can set the standard CMake [CMAKE_MSVC_RUNTIME_LIBRARY][]
variable instead of this GLFW-specific option.
[CMAKE_MSVC_RUNTIME_LIBRARY]: https://cmake.org/cmake/help/latest/variable/CMAKE_MSVC_RUNTIME_LIBRARY.html
@anchor GLFW_USE_HYBRID_HPG
__GLFW_USE_HYBRID_HPG__ determines whether to export the `NvOptimusEnablement` and
`AmdPowerXpressRequestHighPerformance` symbols, which force the use of the
@ -281,15 +278,28 @@ will not work if GLFW is built as a DLL. This is disabled by default, letting
the operating system and driver decide.
@subsection compile_options_wayland Wayland specific CMake options
### macOS specific CMake options {#compile_options_macos}
@anchor GLFW_USE_WAYLAND
__GLFW_USE_WAYLAND__ determines whether to compile the library for Wayland.
This option is only available on Linux and other Unix-like systems other than
macOS. This is disabled by default.
@anchor GLFW_BUILD_COCOA
__GLFW_BUILD_COCOA__ determines whether to include support for Cocoa when compiling the
library. This option is only available when compiling for macOS. This is enabled by
default.
@section compile_mingw_cross Cross-compilation with CMake and MinGW
### Unix-like system specific CMake options {#compile_options_unix}
@anchor GLFW_BUILD_WAYLAND
__GLFW_BUILD_WAYLAND__ determines whether to include support for Wayland when compiling
the library. This option is only available when compiling for Linux and other Unix-like
systems other than macOS. This is enabled by default.
@anchor GLFW_BUILD_X11
__GLFW_BUILD_X11__ determines whether to include support for X11 when compiling the
library. This option is only available when compiling for Linux and other Unix-like
systems other than macOS. This is enabled by default.
## Cross-compilation with CMake and MinGW {#compile_mingw_cross}
Both Cygwin and many Linux distributions have MinGW or MinGW-w64 packages. For
example, Cygwin has the `mingw64-i686-gcc` and `mingw64-x86_64-gcc` packages
@ -301,9 +311,9 @@ cross-compilation of Windows binaries. To use these files you set the
`CMAKE_TOOLCHAIN_FILE` CMake variable with the `-D` flag add an option when
configuring and generating the build files.
@code{.sh}
```sh
cmake -S path/to/glfw -B path/to/build -D CMAKE_TOOLCHAIN_FILE=path/to/file
@endcode
```
The exact toolchain file to use depends on the prefix used by the MinGW or
MinGW-w64 binaries on your system. You can usually see this in the /usr
@ -311,47 +321,44 @@ directory. For example, both the Ubuntu and Cygwin MinGW-w64 packages have
`/usr/x86_64-w64-mingw32` for the 64-bit compilers, so the correct invocation
would be:
@code{.sh}
```sh
cmake -S path/to/glfw -B path/to/build -D CMAKE_TOOLCHAIN_FILE=CMake/x86_64-w64-mingw32.cmake
@endcode
```
The path to the toolchain file is relative to the path to the GLFW source tree
passed to the `-S` flag, not to the current directory.
For more details see the
[CMake toolchain guide](https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html).
For more details see the [CMake toolchain guide][cmake-toolchains].
[cmake-toolchains]: https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html
@section compile_manual Compiling GLFW manually
## Compiling GLFW manually {#compile_manual}
If you wish to compile GLFW without its CMake build environment then you will
have to do at least some of the platform detection yourself. GLFW needs
a configuration macro to be defined in order to know what window system it is
being compiled for and also has optional, platform-specific ones for various
features.
If you wish to compile GLFW without its CMake build environment then you will have to do
at least some platform-detection yourself. There are preprocessor macros for
enabling support for the platforms (window systems) available. There are also optional,
platform-specific macros for various features.
When building with CMake, the `glfw_config.h` configuration header is generated
based on the current platform and CMake options. The GLFW CMake environment
defines @b GLFW_USE_CONFIG_H, which causes this header to be included by
`internal.h`. Without this macro, GLFW will expect the necessary configuration
macros to be defined on the command-line.
When building, GLFW will expect the necessary configuration macros to be defined
on the command-line. The GLFW CMake files set these as private compile
definitions on the GLFW target but if you compile the GLFW sources manually you
will need to define them yourself.
The window creation API is used to create windows, handle input, monitors, gamma
ramps and clipboard. The options are:
The window system is used to create windows, handle input, monitors, gamma ramps and
clipboard. The options are:
- @b _GLFW_COCOA to use the Cocoa frameworks
- @b _GLFW_WIN32 to use the Win32 API
- @b _GLFW_WAYLAND to use the Wayland protocol
- @b _GLFW_X11 to use the X Window System
- @b _GLFW_WAYLAND to use the Wayland API (experimental and incomplete)
- @b _GLFW_OSMESA to use the OSMesa API (headless and non-interactive)
The @b _GLFW_WAYLAND and @b _GLFW_X11 macros may be combined and produces a library that
attempts to detect the appropriate platform at initialization.
If you are building GLFW as a shared library / dynamic library / DLL then you
must also define @b _GLFW_BUILD_DLL. Otherwise, you must not define it.
If you are linking the Vulkan loader directly with your application then you
must also define @b _GLFW_VULKAN_STATIC. Otherwise, GLFW will attempt to use the
external version.
If you are using a custom name for the Vulkan, EGL, GLX, OSMesa, OpenGL, GLESv1
or GLESv2 library, you can override the default names by defining those you need
of @b _GLFW_VULKAN_LIBRARY, @b _GLFW_EGL_LIBRARY, @b _GLFW_GLX_LIBRARY, @b
@ -362,4 +369,3 @@ _GLFW_GLESV2_LIBRARY. Otherwise, GLFW will use the built-in default names.
GLFW. If you define any of these in your build files, make sure they are not
applied to the GLFW sources.
*/

102
deps/glfw/docs/context.dox → deps/glfw/docs/context.md vendored
View File

@ -1,8 +1,6 @@
/*!
# Context guide {#context_guide}
@page context_guide Context guide
@tableofcontents
[TOC]
This guide introduces the OpenGL and OpenGL ES context related functions of
GLFW. For details on a specific function in this category, see the @ref
@ -15,7 +13,7 @@ context. There are also guides for the other areas of the GLFW API.
- @ref input_guide
@section context_object Context objects
## Context objects {#context_object}
A window object encapsulates both a top-level window and an OpenGL or OpenGL ES
context. It is created with @ref glfwCreateWindow and destroyed with @ref
@ -34,22 +32,22 @@ context creation by setting the [GLFW_CLIENT_API](@ref GLFW_CLIENT_API_hint)
hint to `GLFW_NO_API`. For more information, see the @ref vulkan_guide.
@subsection context_hints Context creation hints
### Context creation hints {#context_hints}
There are a number of hints, specified using @ref glfwWindowHint, related to
what kind of context is created. See
[context related hints](@ref window_hints_ctx) in the window guide.
@subsection context_sharing Context object sharing
### Context object sharing {#context_sharing}
When creating a window and its OpenGL or OpenGL ES context with @ref
glfwCreateWindow, you can specify another window whose context the new one
should share its objects (textures, vertex and element buffers, etc.) with.
@code
```c
GLFWwindow* second_window = glfwCreateWindow(640, 480, "Second Window", NULL, first_window);
@endcode
```
Object sharing is implemented by the operating system and graphics driver. On
platforms where it is possible to choose which types of objects are shared, GLFW
@ -61,20 +59,20 @@ information. The name and number of this chapter unfortunately varies between
versions and APIs, but has at times been named _Shared Objects and Multiple
Contexts_.
GLFW comes with a barebones object sharing example program called `sharing`.
GLFW comes with a bare-bones object sharing example program called `sharing`.
@subsection context_offscreen Offscreen contexts
### Offscreen contexts {#context_offscreen}
GLFW doesn't support creating contexts without an associated window. However,
contexts with hidden windows can be created with the
[GLFW_VISIBLE](@ref GLFW_VISIBLE_hint) window hint.
@code
```c
glfwWindowHint(GLFW_VISIBLE, GLFW_FALSE);
GLFWwindow* offscreen_context = glfwCreateWindow(640, 480, "", NULL, NULL);
@endcode
```
The window never needs to be shown and its context can be used as a plain
offscreen context. Depending on the window manager, the size of a hidden
@ -84,20 +82,17 @@ objects are recommended for rendering with such contexts.
You should still [process events](@ref events) as long as you have at least one
window, even if none of them are visible.
@macos The first time a window is created the menu bar is created. This is not
desirable for example when writing a command-line only application. Menu bar
creation can be disabled with the @ref GLFW_COCOA_MENUBAR init hint.
@subsection context_less Windows without contexts
### Windows without contexts {#context_less}
You can disable context creation by setting the
[GLFW_CLIENT_API](@ref GLFW_CLIENT_API_hint) hint to `GLFW_NO_API`. Windows
without contexts must not be passed to @ref glfwMakeContextCurrent or @ref
glfwSwapBuffers.
[GLFW_CLIENT_API](@ref GLFW_CLIENT_API_hint) hint to `GLFW_NO_API`.
Windows without contexts should not be passed to @ref glfwMakeContextCurrent or
@ref glfwSwapBuffers. Doing this generates a @ref GLFW_NO_WINDOW_CONTEXT error.
@section context_current Current context
## Current context {#context_current}
Before you can make OpenGL or OpenGL ES calls, you need to have a current
context of the correct type. A context can only be current for a single thread
@ -108,15 +103,15 @@ thread before making it current on the new one.
The context of a window is made current with @ref glfwMakeContextCurrent.
@code
```c
glfwMakeContextCurrent(window);
@endcode
```
The window of the current context is returned by @ref glfwGetCurrentContext.
@code
```c
GLFWwindow* window = glfwGetCurrentContext();
@endcode
```
The following GLFW functions require a context to be current. Calling any these
functions without a current context will generate a @ref GLFW_NO_CURRENT_CONTEXT
@ -127,12 +122,12 @@ error.
- @ref glfwGetProcAddress
@section context_swap Buffer swapping
## Buffer swapping {#context_swap}
See @ref buffer_swap in the window guide.
@section context_glext OpenGL and OpenGL ES extensions
## OpenGL and OpenGL ES extensions {#context_glext}
One of the benefits of OpenGL and OpenGL ES is their extensibility.
Hardware vendors may include extensions in their implementations that extend the
@ -155,7 +150,7 @@ their specifications, can be found at the
[OpenGL ES Registry](https://www.khronos.org/registry/gles/).
@subsection context_glext_auto Loading extension with a loader library
### Loading extension with a loader library {#context_glext_auto}
An extension loader library is the easiest and best way to access both OpenGL and
OpenGL ES extensions and modern versions of the core OpenGL or OpenGL ES APIs.
@ -172,9 +167,9 @@ both GLFW and glad, but loaders for OpenGL ES, as well as loaders for specific
API versions and extension sets can be generated. The generated files are
written to the `output` directory.
@code{.sh}
```sh
python main.py --generator c --no-loader --out-path output
@endcode
```
The `--no-loader` option is added because GLFW already provides a function for
loading OpenGL and OpenGL ES function pointers, one that automatically uses the
@ -188,14 +183,14 @@ include the glad header file, which will replace the OpenGL header of your
development environment. By including the glad header before the GLFW header,
it suppresses the development environment's OpenGL or OpenGL ES header.
@code
```c
#include <glad/glad.h>
#include <GLFW/glfw3.h>
@endcode
```
Finally you need to initialize glad once you have a suitable current context.
Finally, you need to initialize glad once you have a suitable current context.
@code
```c
window = glfwCreateWindow(640, 480, "My Window", NULL, NULL);
if (!window)
{
@ -205,11 +200,11 @@ if (!window)
glfwMakeContextCurrent(window);
gladLoadGLLoader((GLADloadproc) glfwGetProcAddress);
@endcode
```
Once glad has been loaded, you have access to all OpenGL core and extension
functions supported by both the context you created and the glad loader you
generated and you are ready to start rendering.
generated. After that, you are ready to start rendering.
You can specify a minimum required OpenGL or OpenGL ES version with
[context hints](@ref window_hints_ctx). If your needs are more complex, you can
@ -218,25 +213,25 @@ check the actual OpenGL or OpenGL ES version with
a specific version is supported by the current context with the
`GLAD_GL_VERSION_x_x` booleans.
@code
```c
if (GLAD_GL_VERSION_3_2)
{
// Call OpenGL 3.2+ specific code
}
@endcode
```
To check whether a specific extension is supported, use the `GLAD_GL_xxx`
booleans.
@code
```c
if (GLAD_GL_ARB_gl_spirv)
{
// Use GL_ARB_gl_spirv
}
@endcode
```
@subsection context_glext_manual Loading extensions manually
### Loading extensions manually {#context_glext_manual}
__Do not use this technique__ unless it is absolutely necessary. An
[extension loader library](@ref context_glext_auto) will save you a ton of
@ -251,7 +246,7 @@ This section will demonstrate manual loading of OpenGL extensions. The loading
of OpenGL ES extensions is identical except for the name of the extension header.
@subsubsection context_glext_header The glext.h header
#### The glext.h header {#context_glext_header}
The `glext.h` extension header is a continually updated file that defines the
interfaces for all OpenGL extensions. The latest version of this can always be
@ -270,41 +265,41 @@ to function) and `PROC` (procedure) are added to the ends.
To include the extension header, define @ref GLFW_INCLUDE_GLEXT before including
the GLFW header.
@code
```c
#define GLFW_INCLUDE_GLEXT
#include <GLFW/glfw3.h>
@endcode
```
@subsubsection context_glext_string Checking for extensions
#### Checking for extensions {#context_glext_string}
A given machine may not actually support the extension (it may have older
drivers or a graphics card that lacks the necessary hardware features), so it
is necessary to check at run-time whether the context supports the extension.
This is done with @ref glfwExtensionSupported.
@code
```c
if (glfwExtensionSupported("GL_ARB_gl_spirv"))
{
// The extension is supported by the current context
}
@endcode
```
The argument is a null terminated ASCII string with the extension name. If the
extension is supported, @ref glfwExtensionSupported returns `GLFW_TRUE`,
otherwise it returns `GLFW_FALSE`.
@subsubsection context_glext_proc Fetching function pointers
#### Fetching function pointers {#context_glext_proc}
Many extensions, though not all, require the use of new OpenGL functions.
These functions often do not have entry points in the client API libraries of
your operating system, making it necessary to fetch them at run time. You can
retrieve pointers to these functions with @ref glfwGetProcAddress.
@code
```c
PFNGLSPECIALIZESHADERARBPROC pfnSpecializeShaderARB = glfwGetProcAddress("glSpecializeShaderARB");
@endcode
```
In general, you should avoid giving the function pointer variables the (exact)
same name as the function, as this may confuse your linker. Instead, you can
@ -313,7 +308,7 @@ use a different prefix, like above, or some other naming scheme.
Now that all the pieces have been introduced, here is what they might look like
when used together.
@code
```c
#define GLFW_INCLUDE_GLEXT
#include <GLFW/glfw3.h>
@ -341,6 +336,5 @@ void some_function(void)
glSpecializeShaderARB(...);
}
}
@endcode
```
*/

3
deps/glfw/docs/extra.css vendored
View File

File diff suppressed because one or more lines are too long

8
deps/glfw/docs/extra.css.map vendored
View File

@ -1 +1,7 @@
{"version":3,"sourceRoot":"","sources":["extra.scss"],"names":[],"mappings":"AA8EA,4GACI,gBACA,iBAGJ,yBACC,yDAGD,6HACC,sDAGD,yIACC,sDAGD,mBACI,WA9EuB,KA+EvB,iBAGJ,uBACC,MAzFoB,QA0FjB,iBAGJ,6UACC,gBAGD,mJACC,YAGD,yHACC,iBAGD,sBACC,gBAGD,4LACC,UAGD,yCACC,aAGD,kMACC,WAnHgC,QAsHjC,KACC,MA1HoB,QA6HrB,sDACC,MA/Ge,QAgHf,mBAGD,GACE,iBACA,eAGF,GACE,iBACA,gBACA,eAGF,GACE,iBACA,gBACA,eAGF,YACC,eACA,gBACA,gBACA,eACA,cAEA,aACA,mBACA,eACA,2BACA,mBACA,sBAGD,UACC,iBACA,mBACA,MA/J0B,KAgK1B,gBACA,qEAGD,YACC,qBACA,kBACA,YAGD,yBACC,WAGD,oCACC,iBACA,gBACA,cACA,MAlL0B,KAqL3B,YACC,eAGD,8CACC,qBAGD,mBACC,MA9L0B,KAiM3B,eACC,kBACA,YACA,eAGD,KACC,WAxM0B,KA2M3B,UACC,gBACA,cACA,eAGD,WACC,gBACA,cACA,eAGD,UACI,aAGJ,mBACI,iBACA,iBAGJ,WACC,gBACA,aACA,mBACA,eACA,2BACA,mBACA,sBAGD,mEACC,MA9OgC,QAiPjC,gCACC,MArPoB,QAwPrB,sCACC,MAjOoB,KAoOrB,yBACC,kBAGD,UACC,iBAGD,wBACC,gBACA,cACA,eACA,qBAGD,uDACC,gEACA,+BACA,+BACA,gBACA,MArPgB,KAwPjB,mBACC,MA5PoB,KA6PpB,aACA,kBACA,yBAGD,QACC,WACA,WAGD,WACC,iBAGD,WACC,mBAGD,WACC,cACA,eACA,qBAGD,oCACC,gEACA,kCACA,2BACA,MAlSe,QAmSf,yBACA,kBAGD,WACC,MA3QuB,QA8QxB,cACC,sBACA,2BACA,4BACA,mBAGD,cACC,sBACA,+BACA,8BACA,gBAGD,mCACC,wBACA,iBACA,sBACA,kBAGD,gIACC,MAxToB,KAyTpB,qBAGD,cACC,wBACA,iBACA,sBACA,kBAGD,iBACC,WACA,4EAGD,oCApSC,gEACA,kCACA,cACA,yBAqSD,wBAxSC,gEACA,kCACA,cACA,yBAySD,qBA5SC,gEACA,kCACA,cACA,yBA6SD,gBAhTC,gEACA,kCACA,cACA,yBAiTD,iGACC,kBACA,YACA,2BACA,aAGD,kRACC,cAGD,SACC,oBAGD,0BACC,mBACA,kBACA,YACA,YACA,cACA,2BACA,aAGD,+CACC,MA1YoB,QA6YrB,+BACC,cAGD,sBACC,cAGD,+CACC,cACA,iBAGD,mBACC,cAGD,KACC,aACA","file":"extra.css"}
{
"version": 3,
"mappings": "AA8EA,2GAA4G,CAC3G,UAAU,CAAC,IAAI,CACf,WAAW,CAAC,IAAI,CAGjB,wBAAyB,CACxB,YAAY,CAAC,2CAAsD,CAGpE,4HAA6H,CAC5H,YAAY,CAAC,wCAAuD,CAGrE,wIAAyI,CACxI,YAAY,CAAC,wCAAuD,CAGrE,kBAAmB,CAClB,UAAU,CA9EgB,IAAa,CA+EvC,WAAW,CAAC,IAAI,CAGjB,sBAAuB,CACtB,KAAK,CAzFe,OAAa,CA0FjC,WAAW,CAAC,IAAI,CAGjB,4UAA6U,CAC5U,UAAU,CAAC,IAAI,CAGhB,kJAAmJ,CAClJ,MAAM,CAAC,IAAI,CAGZ,wHAAyH,CACxH,WAAW,CAAC,IAAI,CAGjB,qBAAsB,CACrB,UAAU,CAAC,IAAI,CAGhB,2LAA4L,CAC3L,OAAO,CAAC,CAAC,CAGV,wCAAyC,CACxC,OAAO,CAAC,IAAI,CAGb,iMAAkM,CACjM,UAAU,CApGW,OAA+B,CAuGrD,IAAK,CACJ,KAAK,CA1He,OAAa,CA6HlC,SAAU,CACN,SAAS,CAAE,IAAI,CACf,MAAM,CAAE,aAAa,CAGzB,qDAAsD,CACrD,KAAK,CApHU,OAAa,CAqH5B,aAAa,CAAC,IAAI,CAGnB,EAAG,CACF,WAAW,CAAC,KAAK,CACjB,SAAS,CAAC,IAAI,CAGf,EAAG,CACF,WAAW,CAAC,KAAK,CACjB,aAAa,CAAC,CAAC,CACf,SAAS,CAAC,IAAI,CAGf,EAAG,CACF,WAAW,CAAC,KAAK,CACjB,aAAa,CAAC,CAAC,CACf,SAAS,CAAC,IAAI,CAGf,WAAY,CACX,SAAS,CAAC,IAAI,CACd,UAAU,CAAC,IAAI,CACf,SAAS,CAAC,KAAK,CACf,OAAO,CAAC,MAAM,CACd,MAAM,CAAC,MAAM,CAEb,OAAO,CAAE,IAAI,CACb,cAAc,CAAE,GAAG,CACnB,SAAS,CAAE,IAAI,CACf,eAAe,CAAE,UAAU,CAC3B,WAAW,CAAE,MAAM,CACnB,aAAa,CAAE,OAAO,CAGvB,SAAU,CACT,WAAW,CAAC,IAAI,CAChB,aAAa,CAAC,IAAI,CAClB,KAAK,CApKqB,IAAa,CAqKvC,SAAS,CAAC,KAAK,CACf,UAAU,CAAC,yDAAyD,CAGrE,WAAY,CACX,eAAe,CAAC,IAAI,CACpB,MAAM,CAAC,UAAU,CACjB,KAAK,CAAC,KAAK,CAGZ,wBAAyB,CACxB,KAAK,CAAC,IAAI,CAGX,mCAAoC,CACnC,WAAW,CAAC,IAAI,CAChB,WAAW,CAAC,GAAG,CACf,OAAO,CAAC,KAAK,CACb,KAAK,CAvLqB,IAAa,CA0LxC,WAAY,CACX,YAAY,CAAE,CAAC,CAGhB,6CAA8C,CAC7C,UAAU,CAAC,SAAS,CAGrB,kBAAmB,CAClB,KAAK,CAnMqB,IAAa,CAsMxC,cAAe,CACd,UAAU,CAAC,MAAM,CACjB,OAAO,CAAC,GAAG,CACX,UAAU,CAAC,GAAG,CAGf,IAAK,CACJ,UAAU,CA7MgB,IAAa,CAgNxC,SAAU,CACT,SAAS,CAAC,KAAK,CACf,MAAM,CAAC,MAAM,CACb,SAAS,CAAC,IAAI,CAGf,UAAW,CACV,SAAS,CAAC,KAAK,CACf,MAAM,CAAC,MAAM,CACb,SAAS,CAAC,IAAI,CAGf,SAAU,CACT,OAAO,CAAC,IAAI,CAGb,kBAAmB,CAClB,WAAW,CAAC,IAAI,CAChB,WAAW,CAAC,IAAI,CAGjB,UAAW,CACV,UAAU,CAAC,IAAI,CACf,OAAO,CAAE,IAAI,CACb,cAAc,CAAE,GAAG,CACnB,SAAS,CAAE,IAAI,CACf,eAAe,CAAE,UAAU,CAC3B,WAAW,CAAE,MAAM,CACnB,aAAa,CAAE,OAAO,CAGvB,kBAAmB,CACf,aAAa,CAAE,IAAI,CAGvB,kEAAmE,CAClE,KAAK,CAxOgB,OAA+B,CA2OrD,+BAAgC,CAC/B,KAAK,CA9Pe,OAAa,CAiQlC,qCAAsC,CACrC,KAAK,CA9NoB,IAAsB,CAiOhD,wBAA2B,CAC1B,MAAM,CAAE,UAAU,CAGnB,SAAU,CACT,UAAU,CAAC,KAAK,CAGjB,uBAAwB,CACvB,SAAS,CAAC,KAAK,CACf,MAAM,CAAC,MAAM,CACb,OAAO,CAAC,MAAM,CACd,UAAU,CAAC,SAA8B,CAG1C,sDAAuD,CACtD,UAAU,CAAC,iDAAoF,CAC/F,UAAU,CAAC,mBAAuC,CAClD,WAAW,CAAC,kBAAgD,CAC5D,UAAU,CAAC,IAAI,CACf,KAAK,CAtPa,IAAe,CAyPlC,kBAAmB,CAClB,KAAK,CAzPoB,IAAsB,CA0P/C,OAAO,CAAC,IAAI,CACZ,aAAa,CAAC,GAAG,CACjB,gBAAgB,CAAC,OAAiC,CAGnD,OAAQ,CACP,KAAK,CAAC,KAAK,CACX,KAAK,CAAC,GAAG,CAGV,oCAAoC,CACnC,OAAQ,CACP,KAAK,CAAC,IAAI,CACV,KAAK,CAAC,OAAO,CACb,MAAM,CAAC,CAAC,EAIV,UAAW,CACV,SAAS,CAAC,MAAM,CAGjB,UAAW,CACV,YAAY,CAAC,KAAK,CAGnB,UAAW,CACV,SAAS,CAAC,GAAG,CACb,YAAY,CAAC,CAAC,CACd,eAAe,CAAC,IAAI,CAIjB,mCAAqB,CACjB,WAAW,CAAC,KAAK,CAIzB,mCAAoC,CACnC,UAAU,CAAC,oDAAgF,CAC3F,UAAU,CAAC,sBAAqC,CAChD,WAAW,CAAC,cAA8C,CAC1D,KAAK,CAzTU,OAAa,CA0T5B,MAAM,CAAC,iBAAgC,CACvC,aAAa,CAAC,GAAG,CAGlB,UAAW,CACV,KAAK,CAlSkB,OAAgC,CAqSxD,aAAc,CACb,MAAM,CAAC,cAA+B,CACtC,sBAAsB,CAAC,GAAG,CAC1B,uBAAuB,CAAC,GAAG,CAC3B,aAAa,CAAC,IAAI,CAGnB,aAAc,CACb,MAAM,CAAC,cAA+B,CACtC,0BAA0B,CAAC,GAAG,CAC9B,yBAAyB,CAAC,GAAG,CAC7B,UAAU,CAAC,IAAI,CAGhB,kCAAmC,CAClC,eAAe,CAAC,OAAO,CACvB,cAAc,CAAC,CAAC,CAChB,MAAM,CAAC,cAA+B,CACtC,aAAa,CAAC,GAAG,CAGlB,+HAAgI,CAC/H,KAAK,CAnUoB,IAAsB,CAoU/C,eAAe,CAAC,IAAI,CAGrB,aAAc,CACb,eAAe,CAAC,OAAO,CACvB,cAAc,CAAC,CAAC,CAChB,MAAM,CAAC,cAA+B,CACtC,aAAa,CAAC,GAAG,CAGlB,gBAAiB,CAChB,MAAM,CAAC,GAAG,CACV,UAAU,CAAC,gEAAiH,CAG7H,mCAAoC,CA3TnC,UAAU,CAAC,oDAAuE,CAClF,UAAU,CAAC,sBAAsC,CACjD,KAAK,CAAC,OAAwB,CAC9B,MAAM,CAAC,iBAAmD,CA4T3D,uBAAwB,CA/TvB,UAAU,CAAC,oDAAuE,CAClF,UAAU,CAAC,sBAAsC,CACjD,KAAK,CAAC,OAAwB,CAC9B,MAAM,CAAC,iBAAmD,CAgU3D,oBAAqB,CAnUpB,UAAU,CAAC,oDAAuE,CAClF,UAAU,CAAC,sBAAsC,CACjD,KAAK,CAAC,OAAwB,CAC9B,MAAM,CAAC,iBAAmD,CAoU3D,eAAgB,CAvUf,UAAU,CAAC,oDAAuE,CAClF,UAAU,CAAC,sBAAsC,CACjD,KAAK,CAAC,OAAwB,CAC9B,MAAM,CAAC,iBAAmD,CAwU3D,gGAAiG,CAChG,aAAa,CAAC,GAAG,CACjB,OAAO,CAAC,GAAG,CACX,WAAW,CAAC,cAAwB,CACpC,MAAM,CAAC,KAAK,CAGb,iRAAkR,CACjR,KAAK,CAAC,OAAO,CAGd,QAAS,CACR,WAAW,CAAC,OAAO,CAGpB,yBAA0B,CACzB,UAAU,CAAC,OAAa,CACxB,aAAa,CAAC,GAAG,CACjB,MAAM,CAAC,IAAI,CACX,OAAO,CAAC,GAAG,CACX,QAAQ,CAAC,IAAI,CACb,WAAW,CAAC,cAAuB,CACnC,MAAM,CAAC,KAAK,CAGb,8CAA+C,CAC9C,KAAK,CAjae,OAAa,CAoalC,8BAA+B,CAC9B,KAAK,CAAC,OAAiB,CAGxB,qBAAsB,CACrB,KAAK,CAAC,OAAgB,CAGvB,8CAA+C,CAC9C,KAAK,CAAC,OAA+B,CACrC,WAAW,CAAC,IAAI,CAGjB,kBAAmB,CAClB,KAAK,CAAC,OAAiB,CAGxB,IAAK,CACJ,OAAO,CAAC,IAAI,CACZ,aAAa,CAAC,GAAG",
"sources": ["extra.scss"],
"names": [],
"file": "extra.css"
}

31
deps/glfw/docs/extra.scss vendored
View File

@ -135,6 +135,11 @@ body {
color:$default-text-color;
}
div.title {
font-size: 170%;
margin: 1em 0 0.5em 0;
}
h1,h2,h2.groupheader,h3,div.toc h3,h4,h5,h6,strong,em {
color:$heading-color;
border-bottom:none;
@ -142,13 +147,13 @@ h1,h2,h2.groupheader,h3,div.toc h3,h4,h5,h6,strong,em {
h1 {
padding-top:0.5em;
font-size:180%;
font-size:150%;
}
h2 {
padding-top:0.5em;
margin-bottom:0;
font-size:140%;
font-size:130%;
}
h3 {
@ -250,6 +255,10 @@ address.footer {
align-content: stretch;
}
#main-menu a:focus {
outline-style: none;
}
#main-menu a,#main-menu a:visited,#main-menu a:hover,#main-menu li {
color:$navbar-link-color;
}
@ -293,8 +302,16 @@ dl.reflist dt a.el {
}
div.toc {
float:none;
width:auto;
float:right;
width:35%;
}
@media screen and (max-width:600px) {
div.toc {
float:none;
width:inherit;
margin:0;
}
}
div.toc h3 {
@ -311,6 +328,12 @@ div.toc li {
list-style-type:disc;
}
div.toc {
li.level2, li.level3 {
margin-left:0.5em;
}
}
div.toc,.memproto,div.qindex,div.ah {
background:linear-gradient(to bottom,$toc-background-color2 0%,$toc-background-color1 100%);
box-shadow:inset 0 0 32px $toc-background-color1;

375
deps/glfw/docs/input.dox → deps/glfw/docs/input.md vendored
View File

@ -1,8 +1,6 @@
/*!
# Input guide {#input_guide}
@page input_guide Input guide
@tableofcontents
[TOC]
This guide introduces the input related functions of GLFW. For details on
a specific function in this category, see the @ref input. There are also guides
@ -24,12 +22,12 @@ All input callbacks receive a window handle. By using the
or objects from your callbacks.
To get a better feel for how the various events callbacks behave, run the
`events` test program. It register every callback supported by GLFW and prints
`events` test program. It registers every callback supported by GLFW and prints
out all arguments provided for every event, along with time and sequence
information.
@section events Event processing
## Event processing {#events}
GLFW needs to poll the window system for events both to provide input to the
application and to prove to the window system that the application hasn't locked
@ -42,18 +40,18 @@ There are three functions for processing pending events. @ref glfwPollEvents,
processes only those events that have already been received and then returns
immediately.
@code
```c
glfwPollEvents();
@endcode
```
This is the best choice when rendering continuously, like most games do.
If you only need to update the contents of the window when you receive new
input, @ref glfwWaitEvents is a better choice.
@code
```c
glfwWaitEvents();
@endcode
```
It puts the thread to sleep until at least one event has been received and then
processes all received events. This saves a great deal of CPU cycles and is
@ -62,9 +60,9 @@ useful for, for example, editing tools.
If you want to wait for events but have UI elements or other tasks that need
periodic updates, @ref glfwWaitEventsTimeout lets you specify a timeout.
@code
```c
glfwWaitEventsTimeout(0.7);
@endcode
```
It puts the thread to sleep until at least one event has been received, or until
the specified number of seconds have elapsed. It then processes any received
@ -74,9 +72,9 @@ If the main thread is sleeping in @ref glfwWaitEvents, you can wake it from
another thread by posting an empty event to the event queue with @ref
glfwPostEmptyEvent.
@code
```c
glfwPostEmptyEvent();
@endcode
```
Do not assume that callbacks will _only_ be called in response to the above
functions. While it is necessary to process events in one or more of the ways
@ -91,11 +89,11 @@ a [window size callback](@ref window_size) GLFW will call it in turn with the
new size before everything returns back out of the @ref glfwSetWindowSize call.
@section input_keyboard Keyboard input
## Keyboard input {#input_keyboard}
GLFW divides keyboard input into two categories; key events and character
events. Key events relate to actual physical keyboard keys, whereas character
events relate to the Unicode code points generated by pressing some of them.
events relate to the text that is generated by pressing some of them.
Keys and characters do not map 1:1. A single key press may produce several
characters, and a single character may require several keys to produce. This
@ -103,56 +101,73 @@ may not be the case on your machine, but your users are likely not all using the
same keyboard layout, input method or even operating system as you.
@subsection input_key Key input
### Key input {#input_key}
If you wish to be notified when a physical key is pressed or released or when it
repeats, set a key callback.
@code
```c
glfwSetKeyCallback(window, key_callback);
@endcode
```
The callback function receives the [keyboard key](@ref keys), platform-specific
scancode, key action and [modifier bits](@ref mods).
@code
```c
void key_callback(GLFWwindow* window, int key, int scancode, int action, int mods)
{
if (key == GLFW_KEY_E && action == GLFW_PRESS)
activate_airship();
}
@endcode
```
The action is one of `GLFW_PRESS`, `GLFW_REPEAT` or `GLFW_RELEASE`. The key
will be `GLFW_KEY_UNKNOWN` if GLFW lacks a key token for it, for example
_E-mail_ and _Play_ keys.
The action is one of `GLFW_PRESS`, `GLFW_REPEAT` or `GLFW_RELEASE`. Events with
`GLFW_PRESS` and `GLFW_RELEASE` actions are emitted for every key press. Most
keys will also emit events with `GLFW_REPEAT` actions while a key is held down.
Note that many keyboards have a limit on how many keys being simultaneous held
down that they can detect. This limit is called
[key rollover](https://en.wikipedia.org/wiki/Key_rollover).
Key events with `GLFW_REPEAT` actions are intended for text input. They are
emitted at the rate set in the user's keyboard settings. At most one key is
repeated even if several keys are held down. `GLFW_REPEAT` actions should not
be relied on to know which keys are being held down or to drive animation.
Instead you should either save the state of relevant keys based on `GLFW_PRESS`
and `GLFW_RELEASE` actions, or call @ref glfwGetKey, which provides basic cached
key state.
The key will be one of the existing [key tokens](@ref keys), or
`GLFW_KEY_UNKNOWN` if GLFW lacks a token for it, for example _E-mail_ and _Play_
keys.
The scancode is unique for every key, regardless of whether it has a key token.
Scancodes are platform-specific but consistent over time, so keys will have
different scancodes depending on the platform but they are safe to save to disk.
You can query the scancode for any [named key](@ref keys) on the current
platform with @ref glfwGetKeyScancode.
You can query the scancode for any [key token](@ref keys) supported on the
current platform with @ref glfwGetKeyScancode.
@code
```c
const int scancode = glfwGetKeyScancode(GLFW_KEY_X);
set_key_mapping(scancode, swap_weapons);
@endcode
```
The last reported state for every [named key](@ref keys) is also saved in
per-window state arrays that can be polled with @ref glfwGetKey.
The last reported state for every physical key with a [key token](@ref keys) is
also saved in per-window state arrays that can be polled with @ref glfwGetKey.
@code
```c
int state = glfwGetKey(window, GLFW_KEY_E);
if (state == GLFW_PRESS)
{
activate_airship();
}
@endcode
```
The returned state is one of `GLFW_PRESS` or `GLFW_RELEASE`.
This function only returns cached key event state. It does not poll the
system for the current physical state of the key.
system for the current state of the physical key. It also does not provide any
key repeat information.
@anchor GLFW_STICKY_KEYS
Whenever you poll state, you risk missing the state change you are looking for.
@ -160,9 +175,9 @@ If a pressed key is released again before you poll its state, you will have
missed the key press. The recommended solution for this is to use a
key callback, but there is also the `GLFW_STICKY_KEYS` input mode.
@code
```c
glfwSetInputMode(window, GLFW_STICKY_KEYS, GLFW_TRUE);
@endcode
```
When sticky keys mode is enabled, the pollable state of a key will remain
`GLFW_PRESS` until the state of that key is polled with @ref glfwGetKey. Once
@ -173,9 +188,9 @@ the state will reset to `GLFW_RELEASE`, otherwise it will remain `GLFW_PRESS`.
If you wish to know what the state of the Caps Lock and Num Lock keys was when
input events were generated, set the `GLFW_LOCK_KEY_MODS` input mode.
@code
```c
glfwSetInputMode(window, GLFW_LOCK_KEY_MODS, GLFW_TRUE);
@endcode
```
When this input mode is enabled, any callback that receives
[modifier bits](@ref mods) will have the @ref GLFW_MOD_CAPS_LOCK bit set if Caps
@ -183,15 +198,15 @@ Lock was on when the event occurred and the @ref GLFW_MOD_NUM_LOCK bit set if
Num Lock was on.
The `GLFW_KEY_LAST` constant holds the highest value of any
[named key](@ref keys).
[key token](@ref keys).
@subsection input_char Text input
### Text input {#input_char}
GLFW supports text input in the form of a stream of
[Unicode code points](https://en.wikipedia.org/wiki/Unicode), as produced by the
operating system text input system. Unlike key input, text input obeys keyboard
layouts and modifier keys and supports composing characters using
operating system text input system. Unlike key input, text input is affected by
keyboard layouts and modifier keys and supports composing characters using
[dead keys](https://en.wikipedia.org/wiki/Dead_key). Once received, you can
encode the code points into UTF-8 or any other encoding you prefer.
@ -200,30 +215,30 @@ you can treat the code point argument as native endian UTF-32.
If you wish to offer regular text input, set a character callback.
@code
```c
glfwSetCharCallback(window, character_callback);
@endcode
```
The callback function receives Unicode code points for key events that would
have led to regular text input and generally behaves as a standard text field on
that platform.
@code
```c
void character_callback(GLFWwindow* window, unsigned int codepoint)
{
}
@endcode
```
@subsection input_key_name Key names
### Key names {#input_key_name}
If you wish to refer to keys by name, you can query the keyboard layout
dependent name of printable keys with @ref glfwGetKeyName.
@code
```c
const char* key_name = glfwGetKeyName(GLFW_KEY_W, 0);
show_tutorial_hint("Press %s to move forward", key_name);
@endcode
```
This function can handle both [keys and scancodes](@ref input_key). If the
specified key is `GLFW_KEY_UNKNOWN` then the scancode is used, otherwise it is
@ -231,42 +246,42 @@ ignored. This matches the behavior of the key callback, meaning the callback
arguments can always be passed unmodified to this function.
@section input_mouse Mouse input
## Mouse input {#input_mouse}
Mouse input comes in many forms, including mouse motion, button presses and
scrolling offsets. The cursor appearance can also be changed, either to
a custom image or a standard cursor shape from the system theme.
@subsection cursor_pos Cursor position
### Cursor position {#cursor_pos}
If you wish to be notified when the cursor moves over the window, set a cursor
position callback.
@code
```c
glfwSetCursorPosCallback(window, cursor_position_callback);
@endcode
```
The callback functions receives the cursor position, measured in screen
coordinates but relative to the top-left corner of the window content area. On
platforms that provide it, the full sub-pixel cursor position is passed on.
@code
```c
static void cursor_position_callback(GLFWwindow* window, double xpos, double ypos)
{
}
@endcode
```
The cursor position is also saved per-window and can be polled with @ref
glfwGetCursorPos.
@code
```c
double xpos, ypos;
glfwGetCursorPos(window, &xpos, &ypos);
@endcode
```
@subsection cursor_mode Cursor mode
### Cursor mode {#cursor_mode}
@anchor GLFW_CURSOR
The `GLFW_CURSOR` input mode provides several cursor modes for special forms of
@ -278,9 +293,9 @@ If you wish to implement mouse motion based camera controls or other input
schemes that require unlimited mouse movement, set the cursor mode to
`GLFW_CURSOR_DISABLED`.
@code
```c
glfwSetInputMode(window, GLFW_CURSOR, GLFW_CURSOR_DISABLED);
@endcode
```
This will hide the cursor and lock it to the specified window. GLFW will then
take care of all the details of cursor re-centering and offset calculation and
@ -294,22 +309,34 @@ other features of GLFW. It is not supported and will not work as robustly as
If you only wish the cursor to become hidden when it is over a window but still
want it to behave normally, set the cursor mode to `GLFW_CURSOR_HIDDEN`.
@code
```c
glfwSetInputMode(window, GLFW_CURSOR, GLFW_CURSOR_HIDDEN);
@endcode
```
This mode puts no limit on the motion of the cursor.
If you wish the cursor to be visible but confined to the content area of the
window, set the cursor mode to `GLFW_CURSOR_CAPTURED`.
```c
glfwSetInputMode(window, GLFW_CURSOR, GLFW_CURSOR_CAPTURED);
```
The cursor will behave normally inside the content area but will not be able to
leave unless the window loses focus.
To exit out of either of these special modes, restore the `GLFW_CURSOR_NORMAL`
cursor mode.
@code
```c
glfwSetInputMode(window, GLFW_CURSOR, GLFW_CURSOR_NORMAL);
@endcode
```
If the cursor was disabled, this will move it back to its last visible position.
@anchor GLFW_RAW_MOUSE_MOTION
@subsection raw_mouse_motion Raw mouse motion
### Raw mouse motion {#raw_mouse_motion}
When the cursor is disabled, raw (unscaled and unaccelerated) mouse motion can
be enabled if available.
@ -324,16 +351,16 @@ Call @ref glfwRawMouseMotionSupported to check if the current machine provides
raw motion and set the `GLFW_RAW_MOUSE_MOTION` input mode to enable it. It is
disabled by default.
@code
```c
if (glfwRawMouseMotionSupported())
glfwSetInputMode(window, GLFW_RAW_MOUSE_MOTION, GLFW_TRUE);
@endcode
```
If supported, raw mouse motion can be enabled or disabled per-window and at any
time but it will only be provided when the cursor is disabled.
@subsection cursor_object Cursor objects
### Cursor objects {#cursor_object}
GLFW supports creating both custom and system theme cursor images, encapsulated
as @ref GLFWcursor objects. They are created with @ref glfwCreateCursor or @ref
@ -341,13 +368,13 @@ glfwCreateStandardCursor and destroyed with @ref glfwDestroyCursor, or @ref
glfwTerminate, if any remain.
@subsubsection cursor_custom Custom cursor creation
#### Custom cursor creation {#cursor_custom}
A custom cursor is created with @ref glfwCreateCursor, which returns a handle to
the created cursor object. For example, this creates a 16x16 white square
cursor with the hot-spot in the upper-left corner:
@code
```c
unsigned char pixels[16 * 16 * 4];
memset(pixels, 0xff, sizeof(pixels));
@ -357,7 +384,7 @@ image.height = 16;
image.pixels = pixels;
GLFWcursor* cursor = glfwCreateCursor(&image, 0, 0);
@endcode
```
If cursor creation fails, `NULL` will be returned, so it is necessary to check
the return value.
@ -367,39 +394,42 @@ per channel with the red channel first. The pixels are arranged canonically as
sequential rows, starting from the top-left corner.
@subsubsection cursor_standard Standard cursor creation
#### Standard cursor creation {#cursor_standard}
A cursor with a [standard shape](@ref shapes) from the current system cursor
theme can be can be created with @ref glfwCreateStandardCursor.
theme can be created with @ref glfwCreateStandardCursor.
@code
GLFWcursor* cursor = glfwCreateStandardCursor(GLFW_HRESIZE_CURSOR);
@endcode
```c
GLFWcursor* url_cursor = glfwCreateStandardCursor(GLFW_POINTING_HAND_CURSOR);
```
These cursor objects behave in the exact same way as those created with @ref
glfwCreateCursor except that the system cursor theme provides the actual image.
A few of these shapes are not available everywhere. If a shape is unavailable,
`NULL` is returned. See @ref glfwCreateStandardCursor for details.
@subsubsection cursor_destruction Cursor destruction
#### Cursor destruction {#cursor_destruction}
When a cursor is no longer needed, destroy it with @ref glfwDestroyCursor.
@code
```c
glfwDestroyCursor(cursor);
@endcode
```
Cursor destruction always succeeds. If the cursor is current for any window,
that window will revert to the default cursor. This does not affect the cursor
mode. All remaining cursors are destroyed when @ref glfwTerminate is called.
@subsubsection cursor_set Cursor setting
#### Cursor setting {#cursor_set}
A cursor can be set as current for a window with @ref glfwSetCursor.
@code
```c
glfwSetCursor(window, cursor);
@endcode
```
Once set, the cursor image will be used as long as the system cursor is over the
content area of the window and the [cursor mode](@ref cursor_mode) is set
@ -409,26 +439,26 @@ A single cursor may be set for any number of windows.
To revert to the default cursor, set the cursor of that window to `NULL`.
@code
```c
glfwSetCursor(window, NULL);
@endcode
```
When a cursor is destroyed, any window that has it set will revert to the
default cursor. This does not affect the cursor mode.
@subsection cursor_enter Cursor enter/leave events
### Cursor enter/leave events {#cursor_enter}
If you wish to be notified when the cursor enters or leaves the content area of
a window, set a cursor enter/leave callback.
@code
```c
glfwSetCursorEnterCallback(window, cursor_enter_callback);
@endcode
```
The callback function receives the new classification of the cursor.
@code
```c
void cursor_enter_callback(GLFWwindow* window, int entered)
{
if (entered)
@ -440,51 +470,52 @@ void cursor_enter_callback(GLFWwindow* window, int entered)
// The cursor left the content area of the window
}
}
@endcode
```
You can query whether the cursor is currently inside the content area of the
window with the [GLFW_HOVERED](@ref GLFW_HOVERED_attrib) window attribute.
@code
```c
if (glfwGetWindowAttrib(window, GLFW_HOVERED))
{
highlight_interface();
}
@endcode
```
@subsection input_mouse_button Mouse button input
### Mouse button input {#input_mouse_button}
If you wish to be notified when a mouse button is pressed or released, set
a mouse button callback.
@code
```c
glfwSetMouseButtonCallback(window, mouse_button_callback);
@endcode
```
The callback function receives the [mouse button](@ref buttons), button action
and [modifier bits](@ref mods).
@code
```c
void mouse_button_callback(GLFWwindow* window, int button, int action, int mods)
{
if (button == GLFW_MOUSE_BUTTON_RIGHT && action == GLFW_PRESS)
popup_menu();
}
@endcode
```
The action is one of `GLFW_PRESS` or `GLFW_RELEASE`.
Mouse button states for [named buttons](@ref buttons) are also saved in
per-window state arrays that can be polled with @ref glfwGetMouseButton.
The last reported state for every [supported mouse button](@ref buttons) is also
saved in per-window state arrays that can be polled with @ref
glfwGetMouseButton.
@code
```c
int state = glfwGetMouseButton(window, GLFW_MOUSE_BUTTON_LEFT);
if (state == GLFW_PRESS)
{
upgrade_cow();
}
@endcode
```
The returned state is one of `GLFW_PRESS` or `GLFW_RELEASE`.
@ -498,9 +529,9 @@ missed the button press. The recommended solution for this is to use a
mouse button callback, but there is also the `GLFW_STICKY_MOUSE_BUTTONS`
input mode.
@code
```c
glfwSetInputMode(window, GLFW_STICKY_MOUSE_BUTTONS, GLFW_TRUE);
@endcode
```
When sticky mouse buttons mode is enabled, the pollable state of a mouse button
will remain `GLFW_PRESS` until the state of that button is polled with @ref
@ -509,30 +540,30 @@ had been processed in the meantime, the state will reset to `GLFW_RELEASE`,
otherwise it will remain `GLFW_PRESS`.
The `GLFW_MOUSE_BUTTON_LAST` constant holds the highest value of any
[named button](@ref buttons).
[supported mouse button](@ref buttons).
@subsection scrolling Scroll input
### Scroll input {#scrolling}
If you wish to be notified when the user scrolls, whether with a mouse wheel or
touchpad gesture, set a scroll callback.
@code
```c
glfwSetScrollCallback(window, scroll_callback);
@endcode
```
The callback function receives two-dimensional scroll offsets.
@code
```c
void scroll_callback(GLFWwindow* window, double xoffset, double yoffset)
{
}
@endcode
```
A normal mouse wheel, being vertical, provides offsets along the Y-axis.
@section joystick Joystick input
## Joystick input {#joystick}
The joystick functions expose connected joysticks and controllers, with both
referred to as joysticks. It supports up to sixteen joysticks, ranging from
@ -540,17 +571,17 @@ referred to as joysticks. It supports up to sixteen joysticks, ranging from
`GLFW_JOYSTICK_LAST`. You can test whether a [joystick](@ref joysticks) is
present with @ref glfwJoystickPresent.
@code
```c
int present = glfwJoystickPresent(GLFW_JOYSTICK_1);
@endcode
```
Each joystick has zero or more axes, zero or more buttons, zero or more hats,
a human-readable name, a user pointer and an SDL compatible GUID.
When GLFW is initialized, detected joysticks are added to the beginning of
the array. Once a joystick is detected, it keeps its assigned ID until it is
disconnected or the library is terminated, so as joysticks are connected and
disconnected, there may appear gaps in the IDs.
Detected joysticks are added to the beginning of the array. Once a joystick is
detected, it keeps its assigned ID until it is disconnected or the library is
terminated, so as joysticks are connected and disconnected, there may appear
gaps in the IDs.
Joystick axis, button and hat state is updated when polled and does not require
a window to be created or events to be processed. However, if you want joystick
@ -562,30 +593,30 @@ To see all the properties of all connected joysticks in real-time, run the
`joysticks` test program.
@subsection joystick_axis Joystick axis states
### Joystick axis states {#joystick_axis}
The positions of all axes of a joystick are returned by @ref
glfwGetJoystickAxes. See the reference documentation for the lifetime of the
returned array.
@code
```c
int count;
const float* axes = glfwGetJoystickAxes(GLFW_JOYSTICK_5, &count);
@endcode
```
Each element in the returned array is a value between -1.0 and 1.0.
@subsection joystick_button Joystick button states
### Joystick button states {#joystick_button}
The states of all buttons of a joystick are returned by @ref
glfwGetJoystickButtons. See the reference documentation for the lifetime of the
returned array.
@code
```c
int count;
const unsigned char* buttons = glfwGetJoystickButtons(GLFW_JOYSTICK_3, &count);
@endcode
```
Each element in the returned array is either `GLFW_PRESS` or `GLFW_RELEASE`.
@ -594,15 +625,15 @@ glfwGetJoystickHats, the button array by default also includes all hats. See
the reference documentation for @ref glfwGetJoystickButtons for details.
@subsection joystick_hat Joystick hat states
### Joystick hat states {#joystick_hat}
The states of all hats are returned by @ref glfwGetJoystickHats. See the
reference documentation for the lifetime of the returned array.
@code
```c
int count;
const unsigned char* hats = glfwGetJoystickHats(GLFW_JOYSTICK_7, &count);
@endcode
```
Each element in the returned array is one of the following:
@ -622,34 +653,34 @@ The diagonal directions are bitwise combinations of the primary (up, right, down
and left) directions and you can test for these individually by ANDing it with
the corresponding direction.
@code
```c
if (hats[2] & GLFW_HAT_RIGHT)
{
// State of hat 2 could be right-up, right or right-down
}
@endcode
```
For backward compatibility with earlier versions that did not have @ref
glfwGetJoystickHats, all hats are by default also included in the button array.
See the reference documentation for @ref glfwGetJoystickButtons for details.
@subsection joystick_name Joystick name
### Joystick name {#joystick_name}
The human-readable, UTF-8 encoded name of a joystick is returned by @ref
glfwGetJoystickName. See the reference documentation for the lifetime of the
returned string.
@code
```c
const char* name = glfwGetJoystickName(GLFW_JOYSTICK_4);
@endcode
```
Joystick names are not guaranteed to be unique. Two joysticks of the same model
and make may have the same name. Only the [joystick ID](@ref joysticks) is
guaranteed to be unique, and only until that joystick is disconnected.
@subsection joystick_userptr Joystick user pointer
### Joystick user pointer {#joystick_userptr}
Each joystick has a user pointer that can be set with @ref
glfwSetJoystickUserPointer and queried with @ref glfwGetJoystickUserPointer.
@ -660,19 +691,19 @@ terminated.
The initial value of the pointer is `NULL`.
@subsection joystick_event Joystick configuration changes
### Joystick configuration changes {#joystick_event}
If you wish to be notified when a joystick is connected or disconnected, set
a joystick callback.
@code
```c
glfwSetJoystickCallback(joystick_callback);
@endcode
```
The callback function receives the ID of the joystick that has been connected
and disconnected and the event that occurred.
@code
```c
void joystick_callback(int jid, int event)
{
if (event == GLFW_CONNECTED)
@ -684,7 +715,7 @@ void joystick_callback(int jid, int event)
// The joystick was disconnected
}
}
@endcode
```
For joystick connection and disconnection events to be delivered on all
platforms, you need to call one of the [event processing](@ref events)
@ -697,15 +728,17 @@ useful values for a disconnected joystick and only before the monitor callback
returns.
@subsection gamepad Gamepad input
### Gamepad input {#gamepad}
The joystick functions provide unlabeled axes, buttons and hats, with no
indication of where they are located on the device. Their order may also vary
between platforms even with the same device.
To solve this problem the SDL community crowdsourced the
[SDL_GameControllerDB](https://github.com/gabomdq/SDL_GameControllerDB) project,
a database of mappings from many different devices to an Xbox-like gamepad.
[SDL_GameControllerDB][] project, a database of mappings from many different
devices to an Xbox-like gamepad.
[SDL_GameControllerDB]: https://github.com/gabomdq/SDL_GameControllerDB
GLFW supports this mapping format and contains a copy of the mappings
available at the time of release. See @ref gamepad_mapping for how to update
@ -715,12 +748,12 @@ a joystick is connected or the mappings are updated.
You can check whether a joystick is both present and has a gamepad mapping with
@ref glfwJoystickIsGamepad.
@code
```c
if (glfwJoystickIsGamepad(GLFW_JOYSTICK_2))
{
// Use as gamepad
}
@endcode
```
If you are only interested in gamepad input you can use this function instead of
@ref glfwJoystickPresent.
@ -729,13 +762,13 @@ You can query the human-readable name provided by the gamepad mapping with @ref
glfwGetGamepadName. This may or may not be the same as the
[joystick name](@ref joystick_name).
@code
```c
const char* name = glfwGetGamepadName(GLFW_JOYSTICK_7);
@endcode
```
To retrieve the gamepad state of a joystick, call @ref glfwGetGamepadState.
@code
```c
GLFWgamepadstate state;
if (glfwGetGamepadState(GLFW_JOYSTICK_3, &state))
@ -747,7 +780,7 @@ if (glfwGetGamepadState(GLFW_JOYSTICK_3, &state))
input_speed(state.axes[GLFW_GAMEPAD_AXIS_RIGHT_TRIGGER]);
}
@endcode
```
The @ref GLFWgamepadstate struct has two arrays; one for button states and one
for axis states. The values for each button and axis are the same as for the
@ -778,18 +811,17 @@ The `GLFW_GAMEPAD_BUTTON_LAST` and `GLFW_GAMEPAD_AXIS_LAST` constants equal
the largest available index for each array.
@subsection gamepad_mapping Gamepad mappings
### Gamepad mappings {#gamepad_mapping}
GLFW contains a copy of the mappings available in
[SDL_GameControllerDB](https://github.com/gabomdq/SDL_GameControllerDB) at the
time of release. Newer ones can be added at runtime with @ref
GLFW contains a copy of the mappings available in [SDL_GameControllerDB][] at
the time of release. Newer ones can be added at runtime with @ref
glfwUpdateGamepadMappings.
@code
```c
const char* mappings = load_file_contents("game/data/gamecontrollerdb.txt");
glfwUpdateGamepadMappings(mappings);
@endcode
```
This function supports everything from single lines up to and including the
unmodified contents of the whole `gamecontrollerdb.txt` file.
@ -818,7 +850,7 @@ The second value is always the human-readable name of the gamepad.
All subsequent values are in the form `<field>:<value>` and describe the layout
of the mapping. These fields may not all be present and may occur in any order.
The button fields are `a`, `b`, `c`, `d`, `back`, `start`, `guide`, `dpup`,
The button fields are `a`, `b`, `x`, `y`, `back`, `start`, `guide`, `dpup`,
`dpright`, `dpdown`, `dpleft`, `leftshoulder`, `rightshoulder`, `leftstick` and
`rightstick`.
@ -849,25 +881,25 @@ one built into GLFW for Xbox controllers accessed via the XInput API on Windows.
This example has been broken into several lines to fit on the page, but real
gamepad mappings must be a single line.
@code{.unparsed}
```
78696e70757401000000000000000000,XInput Gamepad (GLFW),platform:Windows,a:b0,
b:b1,x:b2,y:b3,leftshoulder:b4,rightshoulder:b5,back:b6,start:b7,leftstick:b8,
rightstick:b9,leftx:a0,lefty:a1,rightx:a2,righty:a3,lefttrigger:a4,
righttrigger:a5,dpup:h0.1,dpright:h0.2,dpdown:h0.4,dpleft:h0.8,
@endcode
```
@note GLFW does not yet support the output range and modifiers `+` and `-` that
were recently added to SDL. The input modifiers `+`, `-` and `~` are supported
and described above.
@section time Time input
## Time input {#time}
GLFW provides high-resolution time input, in seconds, with @ref glfwGetTime.
@code
```c
double seconds = glfwGetTime();
@endcode
```
It returns the number of seconds since the library was initialized with @ref
glfwInit. The platform-specific time sources used typically have micro- or
@ -875,9 +907,9 @@ nanosecond resolution.
You can modify the base time with @ref glfwSetTime.
@code
```c
glfwSetTime(4.0);
@endcode
```
This sets the time to the specified time, in seconds, and it continues to count
from there.
@ -885,32 +917,32 @@ from there.
You can also access the raw timer used to implement the functions above,
with @ref glfwGetTimerValue.
@code
```c
uint64_t value = glfwGetTimerValue();
@endcode
```
This value is in 1&nbsp;/&nbsp;frequency seconds. The frequency of the raw
timer varies depending on the operating system and hardware. You can query the
frequency, in Hz, with @ref glfwGetTimerFrequency.
@code
```c
uint64_t frequency = glfwGetTimerFrequency();
@endcode
```
@section clipboard Clipboard input and output
## Clipboard input and output {#clipboard}
If the system clipboard contains a UTF-8 encoded string or if it can be
converted to one, you can retrieve it with @ref glfwGetClipboardString. See the
reference documentation for the lifetime of the returned string.
@code
```c
const char* text = glfwGetClipboardString(NULL);
if (text)
{
insert_text(text);
}
@endcode
```
If the clipboard is empty or if its contents could not be converted, `NULL` is
returned.
@ -918,33 +950,32 @@ returned.
The contents of the system clipboard can be set to a UTF-8 encoded string with
@ref glfwSetClipboardString.
@code
```c
glfwSetClipboardString(NULL, "A string with words in it");
@endcode
```
@section path_drop Path drop input
## Path drop input {#path_drop}
If you wish to receive the paths of files and/or directories dropped on
a window, set a file drop callback.
@code
```c
glfwSetDropCallback(window, drop_callback);
@endcode
```
The callback function receives an array of paths encoded as UTF-8.
@code
```c
void drop_callback(GLFWwindow* window, int count, const char** paths)
{
int i;
for (i = 0; i < count; i++)
handle_dropped_file(paths[i]);
}
@endcode
```
The path array and its strings are only valid until the file drop callback
returns, as they may have been generated specifically for that event. You need
to make a deep copy of the array if you want to keep the paths.
*/

43
deps/glfw/docs/internal.dox → deps/glfw/docs/internal.md vendored
View File

@ -1,14 +1,12 @@
/*!
# Internal structure {#internals_guide}
@page internals_guide Internal structure
@tableofcontents
[TOC]
There are several interfaces inside GLFW. Each interface has its own area of
responsibility and its own naming conventions.
@section internals_public Public interface
## Public interface {#internals_public}
The most well-known is the public interface, described in the glfw3.h header
file. This is implemented in source files shared by all platforms and these
@ -22,7 +20,7 @@ it use headless camel case.
Examples: `glfwCreateWindow`, `GLFWwindow`, `GLFW_RED_BITS`
@section internals_native Native interface
## Native interface {#internals_native}
The [native interface](@ref native) is a small set of publicly available
but platform-specific functions, described in the glfw3native.h header file and
@ -36,7 +34,7 @@ from.
Examples: `glfwGetX11Window`, `glfwGetWGLContext`
@section internals_internal Internal interface
## Internal interface {#internals_internal}
The internal interface consists of utility functions used by all other
interfaces. It is shared code implemented in the same shared source files as
@ -52,7 +50,7 @@ global names have a leading underscore.
Examples: `_glfwIsValidContextConfig`, `_GLFWwindow`, `_glfw.monitorCount`
@section internals_platform Platform interface
## Platform interface {#internals_platform}
The platform interface implements all platform-specific operations as a service
to the public interface. This includes event processing. The platform
@ -61,12 +59,21 @@ application-provided callbacks. It is also prohibited from modifying the
platform-independent part of the internal structs. Instead, it calls the event
interface when events interesting to GLFW are received.
The platform interface mirrors those parts of the public interface that needs to
perform platform-specific operations on some or all platforms. The are also
named the same except that the glfw function prefix is replaced by
_glfwPlatform.
The platform interface mostly mirrors those parts of the public interface that needs to
perform platform-specific operations on some or all platforms.
Examples: `_glfwPlatformCreateWindow`
The window system bits of the platform API is called through the `_GLFWplatform` struct of
function pointers, to allow runtime selection of platform. This includes the window and
context creation, input and event processing, monitor and Vulkan surface creation parts of
GLFW. This is located in the global `_glfw` struct.
Examples: `_glfw.platform.createWindow`
The timer, threading and module loading bits of the platform API are plain functions with
a `_glfwPlatform` prefix, as these things are independent of what window system is being
used.
Examples: `_glfwPlatformGetTimerValue`
The platform interface also defines structs that contain platform-specific
global and per-object state. Their names mirror those of the internal
@ -81,7 +88,7 @@ prevents shared code from accidentally using these members.
Examples: `window->win32.handle`, `_glfw.x11.display`
@section internals_event Event interface
## Event interface {#internals_event}
The event interface is implemented in the same shared source files as the public
interface and is responsible for delivering the events it receives to the
@ -93,7 +100,7 @@ ObjectEvent pattern.
Examples: `_glfwInputWindowFocus`, `_glfwInputCursorPos`
@section internals_static Static functions
## Static functions {#internals_static}
Static functions may be used by any interface and have no prefixes or suffixes.
These use headless camel case.
@ -101,15 +108,13 @@ These use headless camel case.
Examples: `isValidElementForJoystick`
@section internals_config Configuration macros
## Configuration macros {#internals_config}
GLFW uses a number of configuration macros to select at compile time which
interfaces and code paths to use. They are defined in the glfw_config.h header file,
which is generated from the `glfw_config.h.in` file by CMake.
interfaces and code paths to use. They are defined in the GLFW CMake target.
Configuration macros the same style as tokens in the public interface, except
with a leading underscore.
Examples: `_GLFW_WIN32`, `_GLFW_BUILD_DLL`
*/

313
deps/glfw/docs/intro.dox → deps/glfw/docs/intro.md vendored
View File

@ -1,8 +1,6 @@
/*!
# Introduction to the API {#intro_guide}
@page intro_guide Introduction to the API
@tableofcontents
[TOC]
This guide introduces the basic concepts of GLFW and describes initialization,
error handling and API guarantees and limitations. For a broad but shallow
@ -18,21 +16,24 @@ There are also guides for the other areas of GLFW.
- @ref input_guide
@section intro_init Initialization and termination
## Initialization and termination {#intro_init}
Before most GLFW functions may be called, the library must be initialized.
This initialization checks what features are available on the machine,
enumerates monitors and joysticks, initializes the timer and performs any
required platform-specific initialization.
enumerates monitors, initializes the timer and performs any required
platform-specific initialization.
Only the following functions may be called before the library has been
successfully initialized, and only from the main thread.
- @ref glfwGetVersion
- @ref glfwGetVersionString
- @ref glfwPlatformSupported
- @ref glfwGetError
- @ref glfwSetErrorCallback
- @ref glfwInitHint
- @ref glfwInitAllocator
- @ref glfwInitVulkanLoader
- @ref glfwInit
- @ref glfwTerminate
@ -40,17 +41,17 @@ Calling any other function before successful initialization will cause a @ref
GLFW_NOT_INITIALIZED error.
@subsection intro_init_init Initializing GLFW
### Initializing GLFW {#intro_init_init}
The library is initialized with @ref glfwInit, which returns `GLFW_FALSE` if an
error occurred.
@code
```c
if (!glfwInit())
{
// Handle initialization failure
}
@endcode
```
If any part of initialization fails, any parts that succeeded are terminated as
if @ref glfwTerminate had been called. The library only needs to be initialized
@ -62,15 +63,20 @@ before the application exits. Modern systems are very good at freeing resources
allocated by programs that exit, but GLFW sometimes has to change global system
settings and these might not be restored without termination.
@macos When the library is initialized the main menu and dock icon are created.
These are not desirable for a command-line only program. The creation of the
main menu and dock icon can be disabled with the @ref GLFW_COCOA_MENUBAR init
hint.
@subsection init_hints Initialization hints
### Initialization hints {#init_hints}
Initialization hints are set before @ref glfwInit and affect how the library
behaves until termination. Hints are set with @ref glfwInitHint.
@code
```c
glfwInitHint(GLFW_JOYSTICK_HAT_BUTTONS, GLFW_FALSE);
@endcode
```
The values you set hints to are never reset by GLFW, but they only take effect
during initialization. Once GLFW has been initialized, any values you set will
@ -81,56 +87,214 @@ will only affect their specific platform. Other platforms will ignore them.
Setting these hints requires no platform specific headers or functions.
@subsubsection init_hints_shared Shared init hints
#### Shared init hints {#init_hints_shared}
@anchor GLFW_PLATFORM
__GLFW_PLATFORM__ specifies the platform to use for windowing and input.
Possible values are `GLFW_ANY_PLATFORM`, `GLFW_PLATFORM_WIN32`,
`GLFW_PLATFORM_COCOA`, `GLFW_PLATFORM_WAYLAND`, `GLFW_PLATFORM_X11` and
`GLFW_PLATFORM_NULL`. The default value is `GLFW_ANY_PLATFORM`, which will
choose any platform the library includes support for except for the Null
backend.
@anchor GLFW_JOYSTICK_HAT_BUTTONS
__GLFW_JOYSTICK_HAT_BUTTONS__ specifies whether to also expose joystick hats as
buttons, for compatibility with earlier versions of GLFW that did not have @ref
glfwGetJoystickHats. Possible values are `GLFW_TRUE` and `GLFW_FALSE`.
@anchor GLFW_ANGLE_PLATFORM_TYPE_hint
__GLFW_ANGLE_PLATFORM_TYPE__ specifies the platform type (rendering backend) to
request when using OpenGL ES and EGL via [ANGLE][]. If the requested platform
type is unavailable, ANGLE will use its default. Possible values are one of
`GLFW_ANGLE_PLATFORM_TYPE_NONE`, `GLFW_ANGLE_PLATFORM_TYPE_OPENGL`,
`GLFW_ANGLE_PLATFORM_TYPE_OPENGLES`, `GLFW_ANGLE_PLATFORM_TYPE_D3D9`,
`GLFW_ANGLE_PLATFORM_TYPE_D3D11`, `GLFW_ANGLE_PLATFORM_TYPE_VULKAN` and
`GLFW_ANGLE_PLATFORM_TYPE_METAL`.
@subsubsection init_hints_osx macOS specific init hints
[ANGLE]: https://chromium.googlesource.com/angle/angle/
The ANGLE platform type is specified via the `EGL_ANGLE_platform_angle`
extension. This extension is not used if this hint is
`GLFW_ANGLE_PLATFORM_TYPE_NONE`, which is the default value.
#### macOS specific init hints {#init_hints_osx}
@anchor GLFW_COCOA_CHDIR_RESOURCES_hint
__GLFW_COCOA_CHDIR_RESOURCES__ specifies whether to set the current directory to
the application to the `Contents/Resources` subdirectory of the application's
bundle, if present. Set this with @ref glfwInitHint.
bundle, if present. Possible values are `GLFW_TRUE` and `GLFW_FALSE`. This is
ignored on other platforms.
@anchor GLFW_COCOA_MENUBAR_hint
__GLFW_COCOA_MENUBAR__ specifies whether to create a basic menu bar, either from
a nib or manually, when the first window is created, which is when AppKit is
initialized. Set this with @ref glfwInitHint.
__GLFW_COCOA_MENUBAR__ specifies whether to create the menu bar and dock icon
when GLFW is initialized. This applies whether the menu bar is created from
a nib or manually by GLFW. Possible values are `GLFW_TRUE` and `GLFW_FALSE`.
This is ignored on other platforms.
@subsubsection init_hints_values Supported and default values
#### Wayland specific init hints {#init_hints_wayland}
Initialization hint | Default value | Supported values
------------------------------- | ------------- | ----------------
@ref GLFW_JOYSTICK_HAT_BUTTONS | `GLFW_TRUE` | `GLFW_TRUE` or `GLFW_FALSE`
@ref GLFW_COCOA_CHDIR_RESOURCES | `GLFW_TRUE` | `GLFW_TRUE` or `GLFW_FALSE`
@ref GLFW_COCOA_MENUBAR | `GLFW_TRUE` | `GLFW_TRUE` or `GLFW_FALSE`
@anchor GLFW_WAYLAND_LIBDECOR_hint
__GLFW_WAYLAND_LIBDECOR__ specifies whether to use [libdecor][] for window
decorations where available. Possible values are `GLFW_WAYLAND_PREFER_LIBDECOR`
and `GLFW_WAYLAND_DISABLE_LIBDECOR`. This is ignored on other platforms.
[libdecor]: https://gitlab.freedesktop.org/libdecor/libdecor
@subsection intro_init_terminate Terminating GLFW
#### X11 specific init hints {#init_hints_x11}
@anchor GLFW_X11_XCB_VULKAN_SURFACE_hint
__GLFW_X11_XCB_VULKAN_SURFACE__ specifies whether to prefer the
`VK_KHR_xcb_surface` extension for creating Vulkan surfaces, or whether to use
the `VK_KHR_xlib_surface` extension. Possible values are `GLFW_TRUE` and
`GLFW_FALSE`. This is ignored on other platforms.
#### Supported and default values {#init_hints_values}
Initialization hint | Default value | Supported values
-------------------------------- | ------------------------------- | ----------------
@ref GLFW_PLATFORM | `GLFW_ANY_PLATFORM` | `GLFW_ANY_PLATFORM`, `GLFW_PLATFORM_WIN32`, `GLFW_PLATFORM_COCOA`, `GLFW_PLATFORM_WAYLAND`, `GLFW_PLATFORM_X11` or `GLFW_PLATFORM_NULL`
@ref GLFW_JOYSTICK_HAT_BUTTONS | `GLFW_TRUE` | `GLFW_TRUE` or `GLFW_FALSE`
@ref GLFW_ANGLE_PLATFORM_TYPE | `GLFW_ANGLE_PLATFORM_TYPE_NONE` | `GLFW_ANGLE_PLATFORM_TYPE_NONE`, `GLFW_ANGLE_PLATFORM_TYPE_OPENGL`, `GLFW_ANGLE_PLATFORM_TYPE_OPENGLES`, `GLFW_ANGLE_PLATFORM_TYPE_D3D9`, `GLFW_ANGLE_PLATFORM_TYPE_D3D11`, `GLFW_ANGLE_PLATFORM_TYPE_VULKAN` or `GLFW_ANGLE_PLATFORM_TYPE_METAL`
@ref GLFW_COCOA_CHDIR_RESOURCES | `GLFW_TRUE` | `GLFW_TRUE` or `GLFW_FALSE`
@ref GLFW_COCOA_MENUBAR | `GLFW_TRUE` | `GLFW_TRUE` or `GLFW_FALSE`
@ref GLFW_WAYLAND_LIBDECOR | `GLFW_WAYLAND_PREFER_LIBDECOR` | `GLFW_WAYLAND_PREFER_LIBDECOR` or `GLFW_WAYLAND_DISABLE_LIBDECOR`
@ref GLFW_X11_XCB_VULKAN_SURFACE | `GLFW_TRUE` | `GLFW_TRUE` or `GLFW_FALSE`
### Runtime platform selection {#platform}
GLFW can be compiled for more than one platform (window system) at once. This lets
a single library binary support both Wayland and X11 on Linux and other Unix-like systems.
You can control platform selection via the @ref GLFW_PLATFORM initialization hint. By
default, this is set to @ref GLFW_ANY_PLATFORM, which will look for supported window
systems in order of priority and select the first one it finds. It can also be set to any
specific platform to have GLFW only look for that one.
```c
glfwInitHint(GLFW_PLATFORM, GLFW_PLATFORM_X11);
```
This mechanism also provides the Null platform, which is always supported but needs to be
explicitly requested. This platform is effectively a stub, emulating a window system on
a single 1080p monitor, but will not interact with any actual window system.
```c
glfwInitHint(GLFW_PLATFORM, GLFW_PLATFORM_NULL);
```
You can test whether a library binary was compiled with support for a specific platform
with @ref glfwPlatformSupported.
```c
if (glfwPlatformSupported(GLFW_PLATFORM_WAYLAND))
glfwInitHint(GLFW_PLATFORM, GLFW_PLATFORM_WAYLAND);
```
Once GLFW has been initialized, you can query which platform was selected with @ref
glfwGetPlatform.
```c
int platform = glfwGetPlatform();
```
If you are using any [native access functions](@ref native), especially on Linux and other
Unix-like systems, then you may need to check that you are calling the ones matching the
selected platform.
### Custom heap memory allocator {#init_allocator}
The heap memory allocator can be customized before initialization with @ref
glfwInitAllocator.
```c
GLFWallocator allocator;
allocator.allocate = my_malloc;
allocator.reallocate = my_realloc;
allocator.deallocate = my_free;
allocator.user = NULL;
glfwInitAllocator(&allocator);
```
The allocator will be made active at the beginning of initialization and will be used by
GLFW until the library has been fully terminated. Any allocator set after initialization
will be picked up only at the next initialization.
The allocator will only be used for allocations that would have been made with
the C standard library. Memory allocations that must be made with platform
specific APIs will still use those.
The allocation function must have a signature matching @ref GLFWallocatefun. It receives
the desired size, in bytes, and the user pointer passed to @ref glfwInitAllocator and
returns the address to the allocated memory block.
```c
void* my_malloc(size_t size, void* user)
{
...
}
```
The documentation for @ref GLFWallocatefun also lists the requirements and limitations for
an allocation function. If the active one does not meet all of these, GLFW may fail.
The reallocation function must have a function signature matching @ref GLFWreallocatefun.
It receives the memory block to be reallocated, the new desired size, in bytes, and the user
pointer passed to @ref glfwInitAllocator and returns the address to the resized memory
block.
```c
void* my_realloc(void* block, size_t size, void* user)
{
...
}
```
The documentation for @ref GLFWreallocatefun also lists the requirements and limitations
for a reallocation function. If the active one does not meet all of these, GLFW may fail.
The deallocation function must have a function signature matching @ref GLFWdeallocatefun.
It receives the memory block to be deallocated and the user pointer passed to @ref
glfwInitAllocator.
```c
void my_free(void* block, void* user)
{
...
}
```
The documentation for @ref GLFWdeallocatefun also lists the requirements and limitations
for a deallocation function. If the active one does not meet all of these, GLFW may fail.
### Terminating GLFW {#intro_init_terminate}
Before your application exits, you should terminate the GLFW library if it has
been initialized. This is done with @ref glfwTerminate.
@code
```c
glfwTerminate();
@endcode
```
This will destroy any remaining window, monitor and cursor objects, restore any
modified gamma ramps, re-enable the screensaver if it had been disabled and free
any other resources allocated by GLFW.
Once the library is terminated, it is as if it had never been initialized and
Once the library is terminated, it is as if it had never been initialized, therefore
you will need to initialize it again before being able to use GLFW. If the
library was not initialized or had already been terminated, it return
library was not initialized or had already been terminated, it returns
immediately.
@section error_handling Error handling
## Error handling {#error_handling}
Some GLFW functions have return values that indicate an error, but this is often
not very helpful when trying to figure out what happened or why it occurred.
@ -141,12 +305,12 @@ values.
The last [error code](@ref errors) for the calling thread can be queried at any
time with @ref glfwGetError.
@code
```c
int code = glfwGetError(NULL);
if (code != GLFW_NO_ERROR)
handle_error(code);
@endcode
```
If no error has occurred since the last call, @ref GLFW_NO_ERROR (zero) is
returned. The error is cleared before the function returns.
@ -160,13 +324,13 @@ can retrieve a UTF-8 encoded human-readable description along with the error
code. If no error has occurred since the last call, the description is set to
`NULL`.
@code
```c
const char* description;
int code = glfwGetError(&description);
if (description)
display_error_message(code, description);
@endcode
```
The retrieved description string is only valid until the next error occurs.
This means you must make a copy of it if you want to keep it.
@ -174,19 +338,19 @@ This means you must make a copy of it if you want to keep it.
You can also set an error callback, which will be called each time an error
occurs. It is set with @ref glfwSetErrorCallback.
@code
```c
glfwSetErrorCallback(error_callback);
@endcode
```
The error callback receives the same error code and human-readable description
returned by @ref glfwGetError.
@code
```c
void error_callback(int code, const char* description)
{
display_error_message(code, description);
}
@endcode
```
The error callback is called after the error is stored, so calling @ref
glfwGetError from within the error callback returns the same values as the
@ -205,7 +369,7 @@ Do not rely on a currently invalid call to generate a specific error, as in the
future that same call may generate a different error or become valid.
@section coordinate_systems Coordinate systems
## Coordinate systems {#coordinate_systems}
GLFW has two primary coordinate systems: the _virtual screen_ and the window
_content area_ or _content area_. Both use the same unit: _virtual screen
@ -242,18 +406,18 @@ between screen coordinates and pixels may also change at run-time depending on
which monitor the window is currently considered to be on.
@section guarantees_limitations Guarantees and limitations
## Guarantees and limitations {#guarantees_limitations}
This section describes the conditions under which GLFW can be expected to
function, barring bugs in the operating system or drivers. Use of GLFW outside
of these limits may work on some platforms, or on some machines, or some of the
these limits may work on some platforms, or on some machines, or some of the
time, or on some versions of GLFW, but it may break at any time and this will
not be considered a bug.
@subsection lifetime Pointer lifetimes
### Pointer lifetimes {#lifetime}
GLFW will never free any pointer you provide to it and you must never free any
GLFW will never free any pointer you provide to it, and you must never free any
pointer it provides to you.
Many GLFW functions return pointers to dynamically allocated structures, strings
@ -271,7 +435,7 @@ Pointer lifetimes are guaranteed not to be shortened in future minor or patch
releases.
@subsection reentrancy Reentrancy
### Reentrancy {#reentrancy}
GLFW event processing and object destruction are not reentrant. This means that
the following functions must not be called from any callback function:
@ -287,7 +451,7 @@ These functions may be made reentrant in future minor or patch releases, but
functions not on this list will not be made non-reentrant.
@subsection thread_safety Thread safety
### Thread safety {#thread_safety}
Most GLFW functions must only be called from the main thread (the thread that
calls main), but some may be called from any thread once the library has been
@ -346,6 +510,11 @@ Library version information may be queried from any thread.
- @ref glfwGetVersion
- @ref glfwGetVersionString
Platform information may be queried from any thread.
- @ref glfwPlatformSupported
- @ref glfwGetPlatform
All Vulkan related functions may be called from any thread.
- @ref glfwVulkanSupported
@ -363,7 +532,7 @@ but functions that are currently limited to the main thread may be updated to
allow calls from any thread in future releases.
@subsection compatibility Version compatibility
### Version compatibility {#compatibility}
GLFW uses [Semantic Versioning](https://semver.org/). This guarantees source
and binary backward compatibility with earlier minor versions of the API. This
@ -383,14 +552,14 @@ fixed in the next release. The reference documentation will also take
precedence over anything stated in a guide.
@subsection event_order Event order
### Event order {#event_order}
The order of arrival of related events is not guaranteed to be consistent
across platforms. The exception is synthetic key and mouse button release
events, which are always delivered after the window defocus event.
@section intro_version Version management
## Version management {#intro_version}
GLFW provides mechanisms for identifying what version of GLFW your application
was compiled against as well as what version it is currently running against.
@ -398,33 +567,33 @@ If you are loading GLFW dynamically (not just linking dynamically), you can use
this to verify that the library binary is compatible with your application.
@subsection intro_version_compile Compile-time version
### Compile-time version {#intro_version_compile}
The compile-time version of GLFW is provided by the GLFW header with the
`GLFW_VERSION_MAJOR`, `GLFW_VERSION_MINOR` and `GLFW_VERSION_REVISION` macros.
@code
```c
printf("Compiled against GLFW %i.%i.%i\n",
GLFW_VERSION_MAJOR,
GLFW_VERSION_MINOR,
GLFW_VERSION_REVISION);
@endcode
```
@subsection intro_version_runtime Run-time version
### Run-time version {#intro_version_runtime}
The run-time version can be retrieved with @ref glfwGetVersion, a function that
may be called regardless of whether GLFW is initialized.
@code
```c
int major, minor, revision;
glfwGetVersion(&major, &minor, &revision);
printf("Running against GLFW %i.%i.%i\n", major, minor, revision);
@endcode
```
@subsection intro_version_string Version string
### Version string {#intro_version_string}
GLFW 3 also provides a compile-time generated version string that describes the
version, platform, compiler and any platform-specific compile-time options.
@ -438,17 +607,31 @@ __Do not use the version string__ to parse the GLFW library version. The @ref
glfwGetVersion function already provides the version of the running library
binary.
__Do not use the version string__ to parse what platforms are supported. The @ref
glfwPlatformSupported function lets you query platform support.
__GLFW 3.4:__ The format of this string was changed to support the addition of
[runtime platform selection](@ref platform).
The format of the string is as follows:
- The version of GLFW
- The name of the window system API
- The name of the context creation API
- Any additional options or APIs
- For each supported platform:
- The name of the window system API
- The name of the window system specific context creation API, if applicable
- The names of the always supported context creation APIs EGL and OSMesa
- Any additional compile-time options, APIs and (on Windows) what compiler was used
For example, when compiling GLFW 3.0 with MinGW using the Win32 and WGL
back ends, the version string may look something like this:
For example, compiling GLFW 3.4 with MinGW as a DLL for Windows, may result in a version string
like this:
@code
3.0.0 Win32 WGL MinGW
@endcode
```c
3.4.0 Win32 WGL Null EGL OSMesa MinGW DLL
```
Compiling GLFW as a static library for Linux, with both Wayland and X11 enabled, may
result in a version string like this:
```c
3.4.0 Wayland X11 GLX Null EGL OSMesa monotonic
```
*/

12
deps/glfw/docs/main.dox → deps/glfw/docs/main.md vendored
View File

@ -1,14 +1,10 @@
/*!
@mainpage notitle
@section main_intro Introduction
# Introduction {#mainpage}
GLFW is a free, Open Source, multi-platform library for OpenGL, OpenGL ES and
Vulkan application development. It provides a simple, platform-independent API
for creating windows, contexts and surfaces, reading input, handling events, etc.
@ref news_33 list new features, caveats and deprecations.
@ref news list new features, caveats and deprecations.
@ref quick_guide is a guide for users new to GLFW. It takes you through how to
write a small but complete program.
@ -33,9 +29,6 @@ use the new API.
There is a section on @ref guarantees_limitations for pointer lifetimes,
reentrancy, thread safety, event order and backward and forward compatibility.
The [FAQ](https://www.glfw.org/faq.html) answers many common questions about the
design, implementation and use of GLFW.
Finally, @ref compat_guide explains what APIs, standards and protocols GLFW uses
and what happens when they are not present on a given machine.
@ -43,4 +36,3 @@ This documentation was generated with Doxygen. The sources for it are available
in both the [source distribution](https://www.glfw.org/download.html) and
[GitHub repository](https://github.com/glfw/glfw).
*/

103
deps/glfw/docs/monitor.dox → deps/glfw/docs/monitor.md vendored
View File

@ -1,8 +1,6 @@
/*!
# Monitor guide {#monitor_guide}
@page monitor_guide Monitor guide
@tableofcontents
[TOC]
This guide introduces the monitor related functions of GLFW. For details on
a specific function in this category, see the @ref monitor. There are also
@ -15,7 +13,7 @@ guides for the other areas of GLFW.
- @ref input_guide
@section monitor_object Monitor objects
## Monitor objects {#monitor_object}
A monitor object represents a currently connected monitor and is represented as
a pointer to the [opaque](https://en.wikipedia.org/wiki/Opaque_data_type) type
@ -36,42 +34,42 @@ To see how GLFW views your monitor setup and its available video modes, run the
`monitors` test program.
@subsection monitor_monitors Retrieving monitors
### Retrieving monitors {#monitor_monitors}
The primary monitor is returned by @ref glfwGetPrimaryMonitor. It is the user's
preferred monitor and is usually the one with global UI elements like task bar
or menu bar.
@code
```c
GLFWmonitor* primary = glfwGetPrimaryMonitor();
@endcode
```
You can retrieve all currently connected monitors with @ref glfwGetMonitors.
See the reference documentation for the lifetime of the returned array.
@code
```c
int count;
GLFWmonitor** monitors = glfwGetMonitors(&count);
@endcode
```
The primary monitor is always the first monitor in the returned array, but other
monitors may be moved to a different index when a monitor is connected or
disconnected.
@subsection monitor_event Monitor configuration changes
### Monitor configuration changes {#monitor_event}
If you wish to be notified when a monitor is connected or disconnected, set
a monitor callback.
@code
```c
glfwSetMonitorCallback(monitor_callback);
@endcode
```
The callback function receives the handle for the monitor that has been
connected or disconnected and the event that occurred.
@code
```c
void monitor_callback(GLFWmonitor* monitor, int event)
{
if (event == GLFW_CONNECTED)
@ -83,7 +81,7 @@ void monitor_callback(GLFWmonitor* monitor, int event)
// The monitor was disconnected
}
}
@endcode
```
If a monitor is disconnected, all windows that are full screen on it will be
switched to windowed mode before the callback is called. Only @ref
@ -91,14 +89,14 @@ glfwGetMonitorName and @ref glfwGetMonitorUserPointer will return useful values
for a disconnected monitor and only before the monitor callback returns.
@section monitor_properties Monitor properties
## Monitor properties {#monitor_properties}
Each monitor has a current video mode, a list of supported video modes,
a virtual position, a content scale, a human-readable name, a user pointer, an
estimated physical size and a gamma ramp.
@subsection monitor_modes Video modes
### Video modes {#monitor_modes}
GLFW generally does a good job selecting a suitable video mode when you create
a full screen window, change its video mode or make a windowed one full
@ -109,101 +107,93 @@ Video modes are represented as @ref GLFWvidmode structures. You can get an
array of the video modes supported by a monitor with @ref glfwGetVideoModes.
See the reference documentation for the lifetime of the returned array.
@code
```c
int count;
GLFWvidmode* modes = glfwGetVideoModes(monitor, &count);
@endcode
```
To get the current video mode of a monitor call @ref glfwGetVideoMode. See the
reference documentation for the lifetime of the returned pointer.
@code
```c
const GLFWvidmode* mode = glfwGetVideoMode(monitor);
@endcode
```
The resolution of a video mode is specified in
[screen coordinates](@ref coordinate_systems), not pixels.
@subsection monitor_size Physical size
### Physical size {#monitor_size}
The physical size of a monitor in millimetres, or an estimation of it, can be
retrieved with @ref glfwGetMonitorPhysicalSize. This has no relation to its
current _resolution_, i.e. the width and height of its current
[video mode](@ref monitor_modes).
@code
```c
int width_mm, height_mm;
glfwGetMonitorPhysicalSize(monitor, &width_mm, &height_mm);
@endcode
```
While this can be used to calculate the raw DPI of a monitor, this is often not
useful. Instead use the [monitor content scale](@ref monitor_scale) and
useful. Instead, use the [monitor content scale](@ref monitor_scale) and
[window content scale](@ref window_scale) to scale your content.
@subsection monitor_scale Content scale
### Content scale {#monitor_scale}
The content scale for a monitor can be retrieved with @ref
glfwGetMonitorContentScale.
@code
```c
float xscale, yscale;
glfwGetMonitorContentScale(monitor, &xscale, &yscale);
@endcode
```
The content scale is the ratio between the current DPI and the platform's
default DPI. This is especially important for text and any UI elements. If the
pixel dimensions of your UI scaled by this look appropriate on your machine then
it should appear at a reasonable size on other machines regardless of their DPI
and scaling settings. This relies on the system DPI and scaling settings being
somewhat correct.
The content scale may depend on both the monitor resolution and pixel density
and on user settings. It may be very different from the raw DPI calculated from
the physical size and current resolution.
For more information on what the content scale is and how to use it, see
[window content scale](@ref window_scale).
@subsection monitor_pos Virtual position
### Virtual position {#monitor_pos}
The position of the monitor on the virtual desktop, in
[screen coordinates](@ref coordinate_systems), can be retrieved with @ref
glfwGetMonitorPos.
@code
```c
int xpos, ypos;
glfwGetMonitorPos(monitor, &xpos, &ypos);
@endcode
```
@subsection monitor_workarea Work area
### Work area {#monitor_workarea}
The area of a monitor not occupied by global task bars or menu bars is the work
area. This is specified in [screen coordinates](@ref coordinate_systems) and
can be retrieved with @ref glfwGetMonitorWorkarea.
@code
```c
int xpos, ypos, width, height;
glfwGetMonitorWorkarea(monitor, &xpos, &ypos, &width, &height);
@endcode
```
@subsection monitor_name Human-readable name
### Human-readable name {#monitor_name}
The human-readable, UTF-8 encoded name of a monitor is returned by @ref
glfwGetMonitorName. See the reference documentation for the lifetime of the
returned string.
@code
```c
const char* name = glfwGetMonitorName(monitor);
@endcode
```
Monitor names are not guaranteed to be unique. Two monitors of the same model
and make may have the same name. Only the monitor handle is guaranteed to be
unique, and only until that monitor is disconnected.
@subsection monitor_userptr User pointer
### User pointer {#monitor_userptr}
Each monitor has a user pointer that can be set with @ref
glfwSetMonitorUserPointer and queried with @ref glfwGetMonitorUserPointer. This
@ -214,12 +204,12 @@ terminated.
The initial value of the pointer is `NULL`.
@subsection monitor_gamma Gamma ramp
### Gamma ramp {#monitor_gamma}
The gamma ramp of a monitor can be set with @ref glfwSetGammaRamp, which accepts
a monitor handle and a pointer to a @ref GLFWgammaramp structure.
@code
```c
GLFWgammaramp ramp;
unsigned short red[256], green[256], blue[256];
@ -234,7 +224,7 @@ for (i = 0; i < ramp.size; i++)
}
glfwSetGammaRamp(monitor, &ramp);
@endcode
```
The gamma ramp data is copied before the function returns, so there is no need
to keep it around once the ramp has been set.
@ -245,24 +235,23 @@ ramp for that monitor.
The current gamma ramp for a monitor is returned by @ref glfwGetGammaRamp. See
the reference documentation for the lifetime of the returned structure.
@code
```c
const GLFWgammaramp* ramp = glfwGetGammaRamp(monitor);
@endcode
```
If you wish to set a regular gamma ramp, you can have GLFW calculate it for you
from the desired exponent with @ref glfwSetGamma, which in turn calls @ref
glfwSetGammaRamp with the resulting ramp.
@code
```c
glfwSetGamma(monitor, 1.0);
@endcode
```
To experiment with gamma correction via the @ref glfwSetGamma function, run the
`gamma` test program.
@note The software controlled gamma ramp is applied _in addition_ to the
hardware gamma correction, which today is usually an approximation of sRGB
hardware gamma correction, which today is typically an approximation of sRGB
gamma. This means that setting a perfectly linear ramp, or gamma 1.0, will
produce the default (usually sRGB-like) behavior.
*/

296
deps/glfw/docs/moving.dox → deps/glfw/docs/moving.md vendored
View File

@ -1,8 +1,6 @@
/*!
# Moving from GLFW 2 to 3 {#moving_guide}
@page moving_guide Moving from GLFW 2 to 3
@tableofcontents
[TOC]
This is a transition guide for moving from GLFW 2 to 3. It describes what has
changed or been removed, but does _not_ include
@ -11,61 +9,64 @@ base onto the new API. For example, the new multi-monitor functions are
required to create full screen windows with GLFW 3.
@section moving_removed Changed and removed features
## Changed and removed features {#moving_removed}
@subsection moving_renamed_files Renamed library and header file
### Renamed library and header file {#moving_renamed_files}
The GLFW 3 header is named @ref glfw3.h and moved to the `GLFW` directory, to
avoid collisions with the headers of other major versions. Similarly, the GLFW
3 library is named `glfw3,` except when it's installed as a shared library on
Unix-like systems, where it uses the
[soname](https://en.wikipedia.org/wiki/soname) `libglfw.so.3`.
Unix-like systems, where it uses the [soname][] `libglfw.so.3`.
@par Old syntax
@code
[soname]: https://en.wikipedia.org/wiki/soname
__Old syntax__
```c
#include <GL/glfw.h>
@endcode
```
@par New syntax
@code
__New syntax__
```c
#include <GLFW/glfw3.h>
@endcode
```
@subsection moving_threads Removal of threading functions
### Removal of threading functions {#moving_threads}
The threading functions have been removed, including the per-thread sleep
function. They were fairly primitive, under-used, poorly integrated and took
time away from the focus of GLFW (i.e. context, input and window). There are
better threading libraries available and native threading support is available
in both [C++11](https://en.cppreference.com/w/cpp/thread) and
[C11](https://en.cppreference.com/w/c/thread), both of which are gaining
traction.
in both [C++11][] and [C11][], both of which are gaining traction.
[C++11]: https://en.cppreference.com/w/cpp/thread
[C11]: https://en.cppreference.com/w/c/thread
If you wish to use the C++11 or C11 facilities but your compiler doesn't yet
support them, see the
[TinyThread++](https://gitorious.org/tinythread/tinythreadpp) and
[TinyCThread](https://github.com/tinycthread/tinycthread) projects created by
support them, see the [TinyThread++][] and [TinyCThread][] projects created by
the original author of GLFW. These libraries implement a usable subset of the
threading APIs in C++11 and C11, and in fact some GLFW 3 test programs use
TinyCThread.
[TinyThread++]: https://gitorious.org/tinythread/tinythreadpp
[TinyCThread]: https://github.com/tinycthread/tinycthread
However, GLFW 3 has better support for _use from multiple threads_ than GLFW
2 had. Contexts can be made current on any thread, although only a single
thread at a time, and the documentation explicitly states which functions may be
used from any thread and which must only be used from the main thread.
@par Removed functions
`glfwSleep`, `glfwCreateThread`, `glfwDestroyThread`, `glfwWaitThread`,
`glfwGetThreadID`, `glfwCreateMutex`, `glfwDestroyMutex`, `glfwLockMutex`,
`glfwUnlockMutex`, `glfwCreateCond`, `glfwDestroyCond`, `glfwWaitCond`,
`glfwSignalCond`, `glfwBroadcastCond` and `glfwGetNumberOfProcessors`.
__Removed functions__
> `glfwSleep`, `glfwCreateThread`, `glfwDestroyThread`, `glfwWaitThread`,
> `glfwGetThreadID`, `glfwCreateMutex`, `glfwDestroyMutex`, `glfwLockMutex`,
> `glfwUnlockMutex`, `glfwCreateCond`, `glfwDestroyCond`, `glfwWaitCond`,
> `glfwSignalCond`, `glfwBroadcastCond` and `glfwGetNumberOfProcessors`.
@par Removed types
`GLFWthreadfun`
__Removed types__
> `GLFWthreadfun`
@subsection moving_image Removal of image and texture loading
### Removal of image and texture loading {#moving_image}
The image and texture loading functions have been removed. They only supported
the Targa image format, making them mostly useful for beginner level examples.
@ -79,94 +80,97 @@ As there already are libraries doing this, it is unnecessary both to duplicate
the work and to tie the duplicate to GLFW. The resulting library would also be
platform-independent, as both OpenGL and stdio are available wherever GLFW is.
@par Removed functions
`glfwReadImage`, `glfwReadMemoryImage`, `glfwFreeImage`, `glfwLoadTexture2D`,
`glfwLoadMemoryTexture2D` and `glfwLoadTextureImage2D`.
__Removed functions__
> `glfwReadImage`, `glfwReadMemoryImage`, `glfwFreeImage`, `glfwLoadTexture2D`,
> `glfwLoadMemoryTexture2D` and `glfwLoadTextureImage2D`.
@subsection moving_stdcall Removal of GLFWCALL macro
### Removal of GLFWCALL macro {#moving_stdcall}
The `GLFWCALL` macro, which made callback functions use
[__stdcall](https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx) on Windows,
has been removed. GLFW is written in C, not Pascal. Removing this macro means
there's one less thing for application programmers to remember, i.e. the
requirement to mark all callback functions with `GLFWCALL`. It also simplifies
the creation of DLLs and DLL link libraries, as there's no need to explicitly
disable `@n` entry point suffixes.
The `GLFWCALL` macro, which made callback functions use [\_\_stdcall][stdcall]
on Windows, has been removed. GLFW is written in C, not Pascal. Removing this
macro means there's one less thing for application programmers to remember, i.e.
the requirement to mark all callback functions with `GLFWCALL`. It also
simplifies the creation of DLLs and DLL link libraries, as there's no need to
explicitly disable `@n` entry point suffixes.
@par Old syntax
@code
[stdcall]: https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx
__Old syntax__
```c
void GLFWCALL callback_function(...);
@endcode
```
@par New syntax
@code
__New syntax__
```c
void callback_function(...);
@endcode
```
@subsection moving_window_handles Window handle parameters
### Window handle parameters {#moving_window_handles}
Because GLFW 3 supports multiple windows, window handle parameters have been
added to all window-related GLFW functions and callbacks. The handle of
a newly created window is returned by @ref glfwCreateWindow (formerly
`glfwOpenWindow`). Window handles are pointers to the
[opaque](https://en.wikipedia.org/wiki/Opaque_data_type) type @ref GLFWwindow.
[opaque][opaque-type] type @ref GLFWwindow.
@par Old syntax
@code
[opaque-type]: https://en.wikipedia.org/wiki/Opaque_data_type
__Old syntax__
```c
glfwSetWindowTitle("New Window Title");
@endcode
```
@par New syntax
@code
__New syntax__
```c
glfwSetWindowTitle(window, "New Window Title");
@endcode
```
@subsection moving_monitor Explicit monitor selection
### Explicit monitor selection {#moving_monitor}
GLFW 3 provides support for multiple monitors. To request a full screen mode window,
instead of passing `GLFW_FULLSCREEN` you specify which monitor you wish the
window to use. The @ref glfwGetPrimaryMonitor function returns the monitor that
GLFW 2 would have selected, but there are many other
[monitor functions](@ref monitor_guide). Monitor handles are pointers to the
[opaque](https://en.wikipedia.org/wiki/Opaque_data_type) type @ref GLFWmonitor.
[opaque][opaque-type] type @ref GLFWmonitor.
@par Old basic full screen
@code
__Old basic full screen__
```c
glfwOpenWindow(640, 480, 8, 8, 8, 0, 24, 0, GLFW_FULLSCREEN);
@endcode
```
@par New basic full screen
@code
__New basic full screen__
```c
window = glfwCreateWindow(640, 480, "My Window", glfwGetPrimaryMonitor(), NULL);
@endcode
```
@note The framebuffer bit depth parameters of `glfwOpenWindow` have been turned
into [window hints](@ref window_hints), but as they have been given
[sane defaults](@ref window_hints_values) you rarely need to set these hints.
@subsection moving_autopoll Removal of automatic event polling
### Removal of automatic event polling {#moving_autopoll}
GLFW 3 does not automatically poll for events in @ref glfwSwapBuffers, meaning
you need to call @ref glfwPollEvents or @ref glfwWaitEvents yourself. Unlike
buffer swap, which acts on a single window, the event processing functions act
on all windows at once.
@par Old basic main loop
@code
__Old basic main loop__
```c
while (...)
{
// Process input
// Render output
glfwSwapBuffers();
}
@endcode
```
@par New basic main loop
@code
__New basic main loop__
```c
while (...)
{
// Process input
@ -174,10 +178,10 @@ while (...)
glfwSwapBuffers(window);
glfwPollEvents();
}
@endcode
```
@subsection moving_context Explicit context management
### Explicit context management {#moving_context}
Each GLFW 3 window has its own OpenGL context and only you, the application
programmer, can know which context should be current on which thread at any
@ -187,7 +191,7 @@ This means that you need to call @ref glfwMakeContextCurrent after creating
a window before you can call any OpenGL functions.
@subsection moving_hidpi Separation of window and framebuffer sizes
### Separation of window and framebuffer sizes {#moving_hidpi}
Window positions and sizes now use screen coordinates, which may not be the same
as pixels on machines with high-DPI monitors. This is important as OpenGL uses
@ -197,20 +201,20 @@ been added. You can retrieve the size of the framebuffer of a window with @ref
glfwGetFramebufferSize function. A framebuffer size callback has also been
added, which can be set with @ref glfwSetFramebufferSizeCallback.
@par Old basic viewport setup
@code
__Old basic viewport setup__
```c
glfwGetWindowSize(&width, &height);
glViewport(0, 0, width, height);
@endcode
```
@par New basic viewport setup
@code
__New basic viewport setup__
```c
glfwGetFramebufferSize(window, &width, &height);
glViewport(0, 0, width, height);
@endcode
```
@subsection moving_window_close Window closing changes
### Window closing changes {#moving_window_close}
The `GLFW_OPENED` window parameter has been removed. As long as the window has
not been destroyed, whether through @ref glfwDestroyWindow or @ref
@ -226,43 +230,43 @@ the window, take some other action or ignore the request.
You can query the close flag at any time with @ref glfwWindowShouldClose and set
it at any time with @ref glfwSetWindowShouldClose.
@par Old basic main loop
@code
__Old basic main loop__
```c
while (glfwGetWindowParam(GLFW_OPENED))
{
...
}
@endcode
```
@par New basic main loop
@code
__New basic main loop__
```c
while (!glfwWindowShouldClose(window))
{
...
}
@endcode
```
The close callback no longer returns a value. Instead, it is called after the
close flag has been set so it can override its value, if it chooses to, before
close flag has been set, so it can optionally override its value, before
event processing completes. You may however not call @ref glfwDestroyWindow
from the close callback (or any other window related callback).
@par Old syntax
@code
__Old syntax__
```c
int GLFWCALL window_close_callback(void);
@endcode
```
@par New syntax
@code
__New syntax__
```c
void window_close_callback(GLFWwindow* window);
@endcode
```
@note GLFW never clears the close flag to `GLFW_FALSE`, meaning you can use it
for other reasons to close the window as well, for example the user choosing
Quit from an in-game menu.
@subsection moving_hints Persistent window hints
### Persistent window hints {#moving_hints}
The `glfwOpenWindowHint` function has been renamed to @ref glfwWindowHint.
@ -271,7 +275,7 @@ instead retain their values until modified by @ref glfwWindowHint or @ref
glfwDefaultWindowHints, or until the library is terminated and re-initialized.
@subsection moving_video_modes Video mode enumeration
### Video mode enumeration {#moving_video_modes}
Video mode enumeration is now per-monitor. The @ref glfwGetVideoModes function
now returns all available modes for a specific monitor instead of requiring you
@ -280,7 +284,7 @@ had poorly defined behavior, has been replaced by @ref glfwGetVideoMode, which
returns the current mode of a monitor.
@subsection moving_char_up Removal of character actions
### Removal of character actions {#moving_char_up}
The action parameter of the [character callback](@ref GLFWcharfun) has been
removed. This was an artefact of the origin of GLFW, i.e. being developed in
@ -288,18 +292,18 @@ 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 ü.
@par Old syntax
@code
__Old syntax__
```c
void GLFWCALL character_callback(int character, int action);
@endcode
```
@par New syntax
@code
__New syntax__
```c
void character_callback(GLFWwindow* window, int character);
@endcode
```
@subsection moving_cursorpos Cursor position changes
### Cursor position changes {#moving_cursorpos}
The `glfwGetMousePos` function has been renamed to @ref glfwGetCursorPos,
`glfwSetMousePos` to @ref glfwSetCursorPos and `glfwSetMousePosCallback` to @ref
@ -315,7 +319,7 @@ glfwSetCursorPos (formerly `glfwSetMousePos`) when that window is active.
Unless the window is active, the function fails silently.
@subsection moving_wheel Wheel position replaced by scroll offsets
### Wheel position replaced by scroll offsets {#moving_wheel}
The `glfwGetMouseWheel` function has been removed. Scrolling is the input of
offsets and has no absolute position. The mouse wheel callback has been
@ -323,21 +327,21 @@ replaced by a [scroll callback](@ref GLFWscrollfun) that receives
two-dimensional floating point scroll offsets. This allows you to receive
precise scroll data from for example modern touchpads.
@par Old syntax
@code
__Old syntax__
```c
void GLFWCALL mouse_wheel_callback(int position);
@endcode
```
@par New syntax
@code
__New syntax__
```c
void scroll_callback(GLFWwindow* window, double xoffset, double yoffset);
@endcode
```
@par Removed functions
`glfwGetMouseWheel`
__Removed functions__
> `glfwGetMouseWheel`
@subsection moving_repeat Key repeat action
### Key repeat action {#moving_repeat}
The `GLFW_KEY_REPEAT` enable has been removed and key repeat is always enabled
for both keys and characters. A new key action, `GLFW_REPEAT`, has been added
@ -346,15 +350,15 @@ from a repeat. Note that @ref glfwGetKey still returns only `GLFW_PRESS` or
`GLFW_RELEASE`.
@subsection moving_keys Physical key input
### Physical key input {#moving_keys}
GLFW 3 key tokens map to physical keys, unlike in GLFW 2 where they mapped to
the values generated by the current keyboard layout. The tokens are named
according to the values they would have using the standard US layout, but this
according to the values they would have in the standard US layout, but this
is only a convenience, as most programmers are assumed to know that layout.
This means that (for example) `GLFW_KEY_LEFT_BRACKET` is always a single key and
is the same key in the same place regardless of what keyboard layouts the users
of your program has.
of your program have.
The key input facility was never meant for text input, although using it that
way worked slightly better in GLFW 2. If you were using it to input text, you
@ -366,7 +370,7 @@ having to remember whether to check for `a` or `A`, you now check for
@ref GLFW_KEY_A.
@subsection moving_joystick Joystick function changes
### Joystick function changes {#moving_joystick}
The `glfwGetJoystickPos` function has been renamed to @ref glfwGetJoystickAxes.
@ -376,18 +380,19 @@ function as well as axis and button counts returned by the @ref
glfwGetJoystickAxes and @ref glfwGetJoystickButtons functions.
@subsection moving_mbcs Win32 MBCS support
### Win32 MBCS support {#moving_mbcs}
The Win32 port of GLFW 3 will not compile in
[MBCS mode](https://msdn.microsoft.com/en-us/library/5z097dxa.aspx).
However, because the use of the Unicode version of the Win32 API doesn't affect
the process as a whole, but only those windows created using it, it's perfectly
The Win32 port of GLFW 3 will not compile in [MBCS mode][MBCS]. However,
because the use of the Unicode version of the Win32 API doesn't affect the
process as a whole, but only those windows created using it, it's perfectly
possible to call MBCS functions from other parts of the same application.
Therefore, even if an application using GLFW has MBCS mode code, there's no need
for GLFW itself to support it.
[MBCS]: https://msdn.microsoft.com/en-us/library/5z097dxa.aspx
@subsection moving_windows Support for versions of Windows older than XP
### Support for versions of Windows older than XP {#moving_windows}
All explicit support for version of Windows older than XP has been removed.
There is no code that actively prevents GLFW 3 from running on these earlier
@ -407,7 +412,7 @@ runtime checking for a number of functions that are present only on modern
version of Windows.
@subsection moving_syskeys Capture of system-wide hotkeys
### Capture of system-wide hotkeys {#moving_syskeys}
The ability to disable and capture system-wide hotkeys like Alt+Tab has been
removed. Modern applications, whether they're games, scientific visualisations
@ -415,7 +420,7 @@ or something else, are nowadays expected to be good desktop citizens and allow
these hotkeys to function even when running in full screen mode.
@subsection moving_terminate Automatic termination
### Automatic termination {#moving_terminate}
GLFW 3 does not register @ref glfwTerminate with `atexit` at initialization,
because `exit` calls registered functions from the calling thread and while it
@ -428,37 +433,41 @@ destroys all windows not already destroyed with @ref glfwDestroyWindow,
invalidating any window handles you may still have.
@subsection moving_glu GLU header inclusion
### GLU header inclusion {#moving_glu}
GLFW 3 does not by default include the GLU header and GLU itself has been
deprecated by [Khronos](https://en.wikipedia.org/wiki/Khronos_Group). __New
projects should not use GLU__, but if you need it for legacy code that
has been moved to GLFW 3, you can request that the GLFW header includes it by
defining @ref GLFW_INCLUDE_GLU before the inclusion of the GLFW header.
deprecated by [Khronos][]. __New projects should not use GLU__, but if you need
it for legacy code that has been moved to GLFW 3, you can request that the GLFW
header includes it by defining @ref GLFW_INCLUDE_GLU before the inclusion of the
GLFW header.
@par Old syntax
@code
[Khronos]: https://en.wikipedia.org/wiki/Khronos_Group
__Old syntax__
```c
#include <GL/glfw.h>
@endcode
```
@par New syntax
@code
__New syntax__
```c
#define GLFW_INCLUDE_GLU
#include <GLFW/glfw3.h>
@endcode
```
There are many libraries that offer replacements for the functionality offered
by GLU. For the matrix helper functions, see math libraries like
[GLM](https://github.com/g-truc/glm) (for C++),
[linmath.h](https://github.com/datenwolf/linmath.h) (for C) and others. For the
tessellation functions, see for example
[libtess2](https://github.com/memononen/libtess2).
by GLU. For the matrix helper functions, see math libraries like [GLM][] (for
C++), [linmath.h][] (for C) and others. For the tessellation functions, see for
example [libtess2][].
[GLM]: https://github.com/g-truc/glm
[linmath.h]: https://github.com/datenwolf/linmath.h
[libtess2]: https://github.com/memononen/libtess2
@section moving_tables Name change tables
## Name change tables {#moving_tables}
@subsection moving_renamed_functions Renamed functions
### Renamed functions {#moving_renamed_functions}
| GLFW 2 | GLFW 3 | Notes |
| --------------------------- | ----------------------------- | ----- |
@ -478,7 +487,7 @@ tessellation functions, see for example
| `glfwGetJoystickParam` | @ref glfwJoystickPresent | The axis and button counts are provided by @ref glfwGetJoystickAxes and @ref glfwGetJoystickButtons |
@subsection moving_renamed_types Renamed types
### Renamed types {#moving_renamed_types}
| GLFW 2 | GLFW 3 | Notes |
| ------------------- | --------------------- | |
@ -486,7 +495,7 @@ tessellation functions, see for example
| `GLFWmouseposfun` | @ref GLFWcursorposfun | |
@subsection moving_renamed_tokens Renamed tokens
### Renamed tokens {#moving_renamed_tokens}
| GLFW 2 | GLFW 3 | Notes |
| --------------------------- | ---------------------------- | ----- |
@ -510,4 +519,3 @@ tessellation functions, see for example
| `GLFW_KEY_RALT` | `GLFW_KEY_RIGHT_ALT` | |
| `GLFW_KEY_RSUPER` | `GLFW_KEY_RIGHT_SUPER` | |
*/

863
deps/glfw/docs/news.dox vendored
View File

@ -1,863 +0,0 @@
/*!
@page news Release notes
@tableofcontents
@section news_33 Release notes for version 3.3
These are the release notes for version 3.3. For a more detailed view including
all fixed bugs see the [version history](https://www.glfw.org/changelog.html).
Please review the caveats, deprecations and removals if your project was written
against an earlier version of GLFW 3.
@subsection features_33 New features in version 3.3
@subsubsection gamepad_33 Gamepad input via SDL_GameControllerDB
GLFW can now remap game controllers to a standard Xbox-like layout using
a built-in copy of SDL_GameControllerDB. Call @ref glfwJoystickIsGamepad to
check if a joystick has a mapping, @ref glfwGetGamepadState to retrieve its
input state, @ref glfwUpdateGamepadMappings to add newer mappings and @ref
glfwGetGamepadName and @ref glfwGetJoystickGUID for mapping related information.
For more information see @ref gamepad.
@subsubsection moltenvk_33 Support for Vulkan on macOS via MoltenVK
GLFW now supports [MoltenVK](https://moltengl.com/moltenvk/), a Vulkan
implementation on top of the Metal API, and its `VK_MVK_macos_surface` window
surface creation extension. MoltenVK is included in the [macOS Vulkan
SDK](https://vulkan.lunarg.com/).
For more information see @ref vulkan_guide.
@subsubsection content_scale_33 Content scale queries for DPI-aware rendering
GLFW now provides content scales for windows and monitors, i.e. the ratio
between their current DPI and the platform's default DPI, with @ref
glfwGetWindowContentScale and @ref glfwGetMonitorContentScale.
Changes of the content scale of a window can be received with the window content
scale callback, set with @ref glfwSetWindowContentScaleCallback.
The @ref GLFW_SCALE_TO_MONITOR window hint enables automatic resizing of a
window by the content scale of the monitor it is placed, on platforms like
Windows where this is necessary. This takes effect both on creation and when
the window is moved between monitors. It is related to but different from
[GLFW_COCOA_RETINA_FRAMEBUFFER](@ref GLFW_COCOA_RETINA_FRAMEBUFFER_hint).
For more information see @ref window_scale.
@subsubsection setwindowattrib_33 Support for updating window attributes
GLFW now supports changing the [GLFW_DECORATED](@ref GLFW_DECORATED_attrib),
[GLFW_RESIZABLE](@ref GLFW_RESIZABLE_attrib),
[GLFW_FLOATING](@ref GLFW_FLOATING_attrib),
[GLFW_AUTO_ICONIFY](@ref GLFW_AUTO_ICONIFY_attrib) and
[GLFW_FOCUS_ON_SHOW](@ref GLFW_FOCUS_ON_SHOW_attrib) attributes for existing
windows with @ref glfwSetWindowAttrib.
For more information see @ref window_attribs.
@subsubsection raw_motion_33 Support for raw mouse motion
GLFW now supports raw (unscaled and unaccelerated) mouse motion in disabled
cursor mode with the [GLFW_RAW_MOUSE_MOTION](@ref GLFW_RAW_MOUSE_MOTION) input
mode. Raw mouse motion input is not yet implemented on macOS. Call @ref
glfwRawMouseMotionSupported to check if GLFW can provide raw mouse motion on the
current system.
For more information see @ref raw_mouse_motion.
@subsubsection joysticks_33 Joystick hats
GLFW can now return the state of hats (i.e. POVs or D-pads) of a joystick with
@ref glfwGetJoystickHats. For compatibility, hats are also exposed as buttons.
This can be disabled with the @ref GLFW_JOYSTICK_HAT_BUTTONS initialization
hint.
For more information see @ref joystick_hat.
@subsubsection geterror_33 Error query
GLFW now supports querying the last error code for the calling thread and its
human-readable description with @ref glfwGetError. This can be used instead of
or together with the error callback.
For more information see @ref error_handling.
@subsubsection init_hints_33 Support for initialization hints
GLFW now supports setting library initialization hints with @ref glfwInitHint.
These must be set before initialization to take effect. Some of these hints are
platform specific but are safe to set on any platform.
For more information see @ref init_hints.
@subsubsection attention_33 User attention request
GLFW now supports requesting user attention with @ref
glfwRequestWindowAttention. Where possible this calls attention to the
specified window. On platforms like macOS it calls attention to the whole
application.
For more information see @ref window_attention.
@subsubsection maximize_33 Window maximization callback
GLFW now supports notifying the application that the window has been maximized
@ref glfwSetWindowMaximizeCallback. This is called both when the window was
maximized by the user and when it was done with @ref glfwMaximizeWindow.
For more information see @ref window_maximize.
@subsubsection workarea_33 Query for the monitor work area
GLFW now supports querying the work area of a monitor, i.e. the area not
occupied by task bars or global menu bars, with @ref glfwGetMonitorWorkarea. On
platforms that lack this concept, the whole area of the monitor is returned.
For more information see @ref monitor_workarea.
@subsubsection transparency_33 Transparent windows and framebuffers
GLFW now supports the creation of windows with transparent framebuffers on
systems with desktop compositing enabled with the @ref
GLFW_TRANSPARENT_FRAMEBUFFER window hint and attribute. This hint must be set
before window creation and leaves any window decorations opaque.
GLFW now also supports whole window transparency with @ref glfwGetWindowOpacity
and @ref glfwSetWindowOpacity. This value controls the opacity of the whole
window including decorations and unlike framebuffer transparency can be changed
at any time after window creation.
For more information see @ref window_transparency.
@subsubsection key_scancode_33 Query for the scancode of a key
GLFW now supports querying the platform dependent scancode of any physical key
with @ref glfwGetKeyScancode.
For more information see @ref input_key.
@subsubsection center_cursor_33 Cursor centering window hint
GLFW now supports controlling whether the cursor is centered over newly created
full screen windows with the [GLFW_CENTER_CURSOR](@ref GLFW_CENTER_CURSOR_hint)
window hint. It is enabled by default.
@subsubsection cursor_hover_33 Mouse cursor hover window attribute
GLFW now supports polling whether the cursor is hovering over the window content
area with the [GLFW_HOVERED](@ref GLFW_HOVERED_attrib) window attribute. This
attribute corresponds to the [cursor enter/leave](@ref cursor_enter) event.
@subsubsection focusonshow_33 Window hint and attribute for input focus on show
GLFW now has the [GLFW_FOCUS_ON_SHOW](@ref GLFW_DECORATED_hint) window hint and
attribute for controlling whether a window gets input focus when shown. It is
enabled by default. It applies both when creating an visible window with @ref
glfwCreateWindow and when showing it with @ref glfwShowWindow.
This is a workaround for GLFW 3.0 lacking @ref glfwFocusWindow and will be
corrected in the next major version.
For more information see @ref window_hide.
@subsubsection device_userptr_33 Monitor and joystick user pointers
GLFW now supports setting and querying user pointers for connected monitors and
joysticks with @ref glfwSetMonitorUserPointer, @ref glfwGetMonitorUserPointer,
@ref glfwSetJoystickUserPointer and @ref glfwGetJoystickUserPointer.
For more information see @ref monitor_userptr and @ref joystick_userptr.
@subsubsection macos_nib_33 macOS menu bar from nib file
GLFW will now load a `MainMenu.nib` file if found in the `Contents/Resources`
directory of the application bundle, as a way to replace the GLFW menu bar
without recompiling GLFW. This behavior can be disabled with the
[GLFW_COCOA_MENUBAR](@ref GLFW_COCOA_MENUBAR_hint) initialization hint.
@subsubsection glext_33 Support for more context creation extensions
The context hint @ref GLFW_SRGB_CAPABLE now supports OpenGL ES via
`WGL_EXT_colorspace`, the context hint @ref GLFW_CONTEXT_NO_ERROR now supports
`WGL_ARB_create_context_no_error` and `GLX_ARB_create_context_no_error`, the
context hint @ref GLFW_CONTEXT_RELEASE_BEHAVIOR now supports
`EGL_KHR_context_flush_control` and @ref glfwGetProcAddress now supports
`EGL_KHR_get_all_proc_addresses`.
@subsubsection osmesa_33 OSMesa off-screen context creation support
GLFW now supports creating off-screen OpenGL contexts using
[OSMesa](https://www.mesa3d.org/osmesa.html) by setting
[GLFW_CONTEXT_CREATION_API](@ref GLFW_CONTEXT_CREATION_API_hint) to
`GLFW_OSMESA_CONTEXT_API`. Native access function have been added to retrieve
the OSMesa color and depth buffers.
There is also a new null backend that uses OSMesa as its native context
creation API, intended for automated testing. This backend does not provide
input.
@subsection caveats_33 Caveats for version 3.3
@subsubsection joystick_layout_33 Layout of joysticks have changed
The way joystick elements are arranged have changed to match SDL2 in order to
support SDL_GameControllerDB mappings. The layout of joysticks may
change again if required for compatibility with SDL2. If you need a known and
stable layout for game controllers, see if you can switch to @ref gamepad.
Existing code that depends on a specific joystick layout will likely have to be
updated.
@subsubsection wait_events_33 No window required to wait for events
The @ref glfwWaitEvents and @ref glfwWaitEventsTimeout functions no longer need
a window to be created to wait for events. Before version 3.3 these functions
would return immediately if there were no user-created windows. On platforms
where only windows can receive events, an internal helper window is used.
Existing code that depends on the earlier behavior will likely have to be
updated.
@subsubsection gamma_ramp_size_33 Gamma ramp size of 256 may be rejected
The documentation for versions before 3.3 stated that a gamma ramp size of 256
would always be accepted. This was never the case on X11 and could lead to
artifacts on macOS. The @ref glfwSetGamma function has been updated to always
generate a ramp of the correct size.
Existing code that hardcodes a size of 256 should be updated to use the size of
the current ramp of a monitor when setting a new ramp for that monitor.
@subsubsection xinput_deadzone_33 Windows XInput deadzone removed
GLFW no longer applies any deadzone to the input state received from the XInput
API. This was never done for any other platform joystick API so this change
makes the behavior more consistent but you will need to apply your own deadzone
if desired.
@subsubsection x11_clipboard_33 X11 clipboard transfer limits
GLFW now supports reading clipboard text via the `INCR` method, which removes
the limit on how much text can be read with @ref glfwGetClipboardString.
However, writing via this method is not yet supported, so you may not be able to
write a very large string with @ref glfwSetClipboardString even if you read it
from the clipboard earlier.
The exact size limit for writing to the clipboard is negotiated with each
receiving application but is at least several tens of kilobytes. Note that only
the read limit has changed. Any string that could be written before still can
be.
@subsubsection x11_linking_33 X11 extension libraries are loaded dynamically
GLFW now loads all X11 extension libraries at initialization. The only X11
library you need to link against is `libX11`. The header files for the
extension libraries are still required for compilation.
Existing projects and makefiles that link GLFW directly against the extension
libraries should still build correctly but will add these libraries as load-time
dependencies.
@subsubsection cmake_version_33 CMake 3.0 or later is required
The minimum CMake version has been raised from 2.8.12 to 3.0. This is only
a requirement of the GLFW CMake files. The GLFW source files do not depend on
CMake.
@subsubsection caveat_fbtransparency_33 Framebuffer transparency requires DWM transparency
GLFW no longer supports framebuffer transparency enabled via @ref
GLFW_TRANSPARENT_FRAMEBUFFER on Windows 7 if DWM transparency is off
(the Transparency setting under Personalization > Window Color).
@subsection deprecations_33 Deprecations in version 3.3
@subsubsection charmods_callback_33 Character with modifiers callback
The character with modifiers callback set with @ref glfwSetCharModsCallback has
been deprecated and should if possible not be used.
Existing code should still work but further bug fixes will likely not be made.
The callback will be removed in the next major version.
@subsubsection clipboard_window_33 Window parameter to clipboard functions
The window parameter of the clipboard functions @ref glfwGetClipboardString and
@ref glfwSetClipboardString has been deprecated and is no longer used on any
platform. On platforms where the clipboard must be owned by a specific window,
an internal helper window is used.
Existing code should still work unless it depends on a specific window owning
the clipboard. New code may pass `NULL` as the window argument. The parameter
will be removed in a future release.
@subsection removals_33 Removals in 3.3
@subsubsection macos_options_33 macOS specific CMake options and macros
The `GLFW_USE_RETINA`, `GLFW_USE_CHDIR` and `GLFW_USE_MENUBAR` CMake options and
the `_GLFW_USE_RETINA`, `_GLFW_USE_CHDIR` and `_GLFW_USE_MENUBAR` compile-time
macros have been removed.
These options and macros are replaced by the window hint
[GLFW_COCOA_RETINA_FRAMEBUFFER](@ref GLFW_COCOA_RETINA_FRAMEBUFFER_hint)
and the init hints
[GLFW_COCOA_CHDIR_RESOURCES](@ref GLFW_COCOA_CHDIR_RESOURCES_hint) and
[GLFW_COCOA_MENUBAR](@ref GLFW_COCOA_MENUBAR_hint).
Existing projects and makefiles that set these options or define these macros
during compilation of GLFW will still build but it will have no effect and the
default behaviors will be used.
@subsubsection vulkan_sdk_33 LunarG Vulkan SDK dependency
The GLFW test programs that previously depended on the LunarG Vulkan SDK now
instead uses a Vulkan loader generated by
[glad2](https://github.com/Dav1dde/glad). This means the GLFW CMake files no
longer look for the Vulkan SDK.
Existing CMake projects that depended on the Vulkan SDK cache variables from
GLFW will need to call `find_package(Vulkan)` themselves. CMake 3.7 and later
already comes with a
[Vulkan find module](https://cmake.org/cmake/help/latest/module/FindVulkan.html)
similar to the one GLFW previously included.
@subsubsection lib_suffix_33 CMake option LIB_SUFFIX
The `LIB_SUFFIX` CMake option has been removed. GLFW now uses the
GNUInstallDirs CMake package to handle platform specific details like the
library directory suffix and the `LIB_SUFFIX` CMake option has been removed.
Existing projects and makefiles that set the `LIB_SUFFIX` option will use the
suffix chosen by the GNUInstallDirs package and the option will be ignored.
@subsubsection mir_removed_33 Mir support
The experimental Mir support has been completely removed as the Mir project has
implemented support for the Wayland protocol and is recommending that
applications use that instead.
Existing projects and makefiles that select Mir when compiling GLFW will fail.
Use Wayland or X11 instead.
@subsection symbols_33 New symbols in version 3.3
@subsubsection functions_33 New functions in version 3.3
- @ref glfwInitHint
- @ref glfwGetError
- @ref glfwGetMonitorWorkarea
- @ref glfwGetMonitorContentScale
- @ref glfwGetMonitorUserPointer
- @ref glfwSetMonitorUserPointer
- @ref glfwWindowHintString
- @ref glfwGetWindowContentScale
- @ref glfwGetWindowOpacity
- @ref glfwSetWindowOpacity
- @ref glfwRequestWindowAttention
- @ref glfwSetWindowAttrib
- @ref glfwSetWindowMaximizeCallback
- @ref glfwSetWindowContentScaleCallback
- @ref glfwRawMouseMotionSupported
- @ref glfwGetKeyScancode
- @ref glfwGetJoystickHats
- @ref glfwGetJoystickGUID
- @ref glfwGetJoystickUserPointer
- @ref glfwSetJoystickUserPointer
- @ref glfwJoystickIsGamepad
- @ref glfwUpdateGamepadMappings
- @ref glfwGetGamepadName
- @ref glfwGetGamepadState
@subsubsection types_33 New types in version 3.3
- @ref GLFWwindowmaximizefun
- @ref GLFWwindowcontentscalefun
- @ref GLFWgamepadstate
@subsubsection constants_33 New constants in version 3.3
- @ref GLFW_NO_ERROR
- @ref GLFW_JOYSTICK_HAT_BUTTONS
- @ref GLFW_COCOA_CHDIR_RESOURCES
- @ref GLFW_COCOA_MENUBAR
- @ref GLFW_CENTER_CURSOR
- @ref GLFW_TRANSPARENT_FRAMEBUFFER
- @ref GLFW_HOVERED
- @ref GLFW_FOCUS_ON_SHOW
- @ref GLFW_SCALE_TO_MONITOR
- @ref GLFW_COCOA_RETINA_FRAMEBUFFER
- @ref GLFW_COCOA_FRAME_NAME
- @ref GLFW_COCOA_GRAPHICS_SWITCHING
- @ref GLFW_X11_CLASS_NAME
- @ref GLFW_X11_INSTANCE_NAME
- @ref GLFW_OSMESA_CONTEXT_API
- @ref GLFW_HAT_CENTERED
- @ref GLFW_HAT_UP
- @ref GLFW_HAT_RIGHT
- @ref GLFW_HAT_DOWN
- @ref GLFW_HAT_LEFT
- @ref GLFW_HAT_RIGHT_UP
- @ref GLFW_HAT_RIGHT_DOWN
- @ref GLFW_HAT_LEFT_UP
- @ref GLFW_HAT_LEFT_DOWN
- @ref GLFW_MOD_CAPS_LOCK
- @ref GLFW_MOD_NUM_LOCK
- @ref GLFW_LOCK_KEY_MODS
- @ref GLFW_RAW_MOUSE_MOTION
- @ref GLFW_GAMEPAD_BUTTON_A
- @ref GLFW_GAMEPAD_BUTTON_B
- @ref GLFW_GAMEPAD_BUTTON_X
- @ref GLFW_GAMEPAD_BUTTON_Y
- @ref GLFW_GAMEPAD_BUTTON_LEFT_BUMPER
- @ref GLFW_GAMEPAD_BUTTON_RIGHT_BUMPER
- @ref GLFW_GAMEPAD_BUTTON_BACK
- @ref GLFW_GAMEPAD_BUTTON_START
- @ref GLFW_GAMEPAD_BUTTON_GUIDE
- @ref GLFW_GAMEPAD_BUTTON_LEFT_THUMB
- @ref GLFW_GAMEPAD_BUTTON_RIGHT_THUMB
- @ref GLFW_GAMEPAD_BUTTON_DPAD_UP
- @ref GLFW_GAMEPAD_BUTTON_DPAD_RIGHT
- @ref GLFW_GAMEPAD_BUTTON_DPAD_DOWN
- @ref GLFW_GAMEPAD_BUTTON_DPAD_LEFT
- @ref GLFW_GAMEPAD_BUTTON_LAST
- @ref GLFW_GAMEPAD_BUTTON_CROSS
- @ref GLFW_GAMEPAD_BUTTON_CIRCLE
- @ref GLFW_GAMEPAD_BUTTON_SQUARE
- @ref GLFW_GAMEPAD_BUTTON_TRIANGLE
- @ref GLFW_GAMEPAD_AXIS_LEFT_X
- @ref GLFW_GAMEPAD_AXIS_LEFT_Y
- @ref GLFW_GAMEPAD_AXIS_RIGHT_X
- @ref GLFW_GAMEPAD_AXIS_RIGHT_Y
- @ref GLFW_GAMEPAD_AXIS_LEFT_TRIGGER
- @ref GLFW_GAMEPAD_AXIS_RIGHT_TRIGGER
- @ref GLFW_GAMEPAD_AXIS_LAST
@section news_32 Release notes for 3.2
These are the release notes for version 3.2. For a more detailed view including
all fixed bugs see the [version history](https://www.glfw.org/changelog.html).
@subsection features_32 New features in version 3.2
@subsubsection news_32_vulkan Support for Vulkan
GLFW now supports basic integration with Vulkan with @ref glfwVulkanSupported,
@ref glfwGetRequiredInstanceExtensions, @ref glfwGetInstanceProcAddress, @ref
glfwGetPhysicalDevicePresentationSupport and @ref glfwCreateWindowSurface.
Vulkan header inclusion can be selected with
@ref GLFW_INCLUDE_VULKAN.
@subsubsection news_32_setwindowmonitor Window mode switching
GLFW now supports switching between windowed and full screen modes and updating
the monitor and desired resolution and refresh rate of full screen windows with
@ref glfwSetWindowMonitor.
@subsubsection news_32_maximize Window maxmimization support
GLFW now supports window maximization with @ref glfwMaximizeWindow and the
@ref GLFW_MAXIMIZED window hint and attribute.
@subsubsection news_32_focus Window input focus control
GLFW now supports giving windows input focus with @ref glfwFocusWindow.
@subsubsection news_32_sizelimits Window size limit support
GLFW now supports setting both absolute and relative window size limits with
@ref glfwSetWindowSizeLimits and @ref glfwSetWindowAspectRatio.
@subsubsection news_32_keyname Localized key names
GLFW now supports querying the localized name of printable keys with @ref
glfwGetKeyName, either by key token or by scancode.
@subsubsection news_32_waittimeout Wait for events with timeout
GLFW now supports waiting for events for a set amount of time with @ref
glfwWaitEventsTimeout.
@subsubsection news_32_icon Window icon support
GLFW now supports setting the icon of windows with @ref glfwSetWindowIcon.
@subsubsection news_32_timer Raw timer access
GLFW now supports raw timer values with @ref glfwGetTimerValue and @ref
glfwGetTimerFrequency.
@subsubsection news_32_joystick Joystick connection callback
GLFW now supports notifying when a joystick has been connected or disconnected
with @ref glfwSetJoystickCallback.
@subsubsection news_32_noapi Context-less windows
GLFW now supports creating windows without a OpenGL or OpenGL ES context by
setting the [GLFW_CLIENT_API](@ref GLFW_CLIENT_API_hint) hint to `GLFW_NO_API`.
@subsubsection news_32_contextapi Run-time context creation API selection
GLFW now supports selecting and querying the context creation API at run-time
with the @ref GLFW_CONTEXT_CREATION_API hint and attribute.
@subsubsection news_32_noerror Error-free context creation
GLFW now supports creating and querying OpenGL and OpenGL ES contexts that do
not emit errors with the @ref GLFW_CONTEXT_NO_ERROR hint, provided the machine
supports the `GL_KHR_no_error` extension.
@subsubsection news_32_cmake CMake config-file package support
GLFW now supports being used as a
[config-file package](@ref build_link_cmake_package) from other projects for
easy linking with the library and its dependencies.
@section news_31 Release notes for 3.1
These are the release notes for version 3.1. For a more detailed view including
all fixed bugs see the [version history](https://www.glfw.org/changelog.html).
@subsection features_31 New features in version 3.1
@subsubsection news_31_cursor Custom mouse cursor images
GLFW now supports creating and setting both custom cursor images and standard
cursor shapes. They are created with @ref glfwCreateCursor or @ref
glfwCreateStandardCursor, set with @ref glfwSetCursor and destroyed with @ref
glfwDestroyCursor.
@see @ref cursor_object
@subsubsection news_31_drop Path drop event
GLFW now provides a callback for receiving the paths of files and directories
dropped onto GLFW windows. The callback is set with @ref glfwSetDropCallback.
@see @ref path_drop
@subsubsection news_31_emptyevent Main thread wake-up
GLFW now provides the @ref glfwPostEmptyEvent function for posting an empty
event from another thread to the main thread event queue, causing @ref
glfwWaitEvents to return.
@see @ref events
@subsubsection news_31_framesize Window frame size query
GLFW now supports querying the size, on each side, of the frame around the
content area of a window, with @ref glfwGetWindowFrameSize.
@see [Window size](@ref window_size)
@subsubsection news_31_autoiconify Simultaneous multi-monitor rendering
GLFW now supports disabling auto-iconification of full screen windows with
the [GLFW_AUTO_ICONIFY](@ref GLFW_AUTO_ICONIFY_hint) window hint. This is
intended for people building multi-monitor installations, where you need windows
to stay in full screen despite losing input focus.
@subsubsection news_31_floating Floating windows
GLFW now supports floating windows, also called topmost or always on top, for
easier debugging with the @ref GLFW_FLOATING window hint and attribute.
@subsubsection news_31_focused Initially unfocused windows
GLFW now supports preventing a windowed mode window from gaining input focus on
creation, with the [GLFW_FOCUSED](@ref GLFW_FOCUSED_hint) window hint.
@subsubsection news_31_direct Direct access for window attributes and cursor position
GLFW now queries the window input focus, visibility and iconification attributes
and the cursor position directly instead of returning cached data.
@subsubsection news_31_charmods Character with modifiers callback
GLFW now provides a callback for character events with modifier key bits. The
callback is set with @ref glfwSetCharModsCallback. Unlike the regular character
callback, this will report character events that will not result in a character
being input, for example if the Control key is held down.
@see @ref input_char
@subsubsection news_31_single Single buffered framebuffers
GLFW now supports the creation of single buffered windows, with the @ref
GLFW_DOUBLEBUFFER hint.
@subsubsection news_31_glext Macro for including extension header
GLFW now includes the extension header appropriate for the chosen OpenGL or
OpenGL ES header when @ref GLFW_INCLUDE_GLEXT is defined. GLFW does not provide
these headers. They must be provided by your development environment or your
OpenGL or OpenGL ES SDK.
@subsubsection news_31_release Context release behaviors
GLFW now supports controlling and querying whether the pipeline is flushed when
a context is made non-current, with the @ref GLFW_CONTEXT_RELEASE_BEHAVIOR hint
and attribute, provided the machine supports the `GL_KHR_context_flush_control`
extension.
@subsubsection news_31_wayland (Experimental) Wayland support
GLFW now has an _experimental_ Wayland display protocol backend that can be
selected on Linux with a CMake option.
@subsubsection news_31_mir (Experimental) Mir support
GLFW now has an _experimental_ Mir display server backend that can be selected
on Linux with a CMake option.
@section news_30 Release notes for 3.0
These are the release notes for version 3.0. For a more detailed view including
all fixed bugs see the [version history](https://www.glfw.org/changelog.html).
@subsection features_30 New features in version 3.0
@subsubsection news_30_cmake CMake build system
GLFW now uses the CMake build system instead of the various makefiles and
project files used by earlier versions. CMake is available for all platforms
supported by GLFW, is present in most package systems and can generate
makefiles and/or project files for most popular development environments.
For more information on how to use CMake, see the
[CMake manual](https://cmake.org/cmake/help/documentation.html).
@subsubsection news_30_multiwnd Multi-window support
GLFW now supports the creation of multiple windows, each with their own OpenGL
or OpenGL ES context, and all window functions now take a window handle. Event
callbacks are now per-window and are provided with the handle of the window that
received the event. The @ref glfwMakeContextCurrent function has been added to
select which context is current on a given thread.
@subsubsection news_30_multimon Multi-monitor support
GLFW now explicitly supports multiple monitors. They can be enumerated with
@ref glfwGetMonitors, queried with @ref glfwGetVideoModes, @ref
glfwGetMonitorPos, @ref glfwGetMonitorName and @ref glfwGetMonitorPhysicalSize,
and specified at window creation to make the newly created window full screen on
that specific monitor.
@subsubsection news_30_unicode Unicode support
All string arguments to GLFW functions and all strings returned by GLFW now use
the UTF-8 encoding. This includes the window title, error string, clipboard
text, monitor and joystick names as well as the extension function arguments (as
ASCII is a subset of UTF-8).
@subsubsection news_30_clipboard Clipboard text I/O
GLFW now supports reading and writing plain text to and from the system
clipboard, with the @ref glfwGetClipboardString and @ref glfwSetClipboardString
functions.
@subsubsection news_30_gamma Gamma ramp support
GLFW now supports setting and reading back the gamma ramp of monitors, with the
@ref glfwGetGammaRamp and @ref glfwSetGammaRamp functions. There is also @ref
glfwSetGamma, which generates a ramp from a gamma value and then sets it.
@subsubsection news_30_gles OpenGL ES support
GLFW now supports the creation of OpenGL ES contexts, by setting the
[GLFW_CLIENT_API](@ref GLFW_CLIENT_API_hint) hint to `GLFW_OPENGL_ES_API`, where
creation of such contexts are supported. Note that GLFW _does not implement_
OpenGL ES, so your driver must provide support in a way usable by GLFW. Modern
Nvidia and Intel drivers support creation of OpenGL ES context using the GLX and
WGL APIs, while AMD provides an EGL implementation instead.
@subsubsection news_30_egl (Experimental) EGL support
GLFW now has an experimental EGL context creation back end that can be selected
through CMake options.
@subsubsection news_30_hidpi High-DPI support
GLFW now supports high-DPI monitors on both Windows and macOS, giving windows
full resolution framebuffers where other UI elements are scaled up. To achieve
this, @ref glfwGetFramebufferSize and @ref glfwSetFramebufferSizeCallback have
been added. These work with pixels, while the rest of the GLFW API works with
screen coordinates. This is important as OpenGL uses pixels, not screen
coordinates.
@subsubsection news_30_error Error callback
GLFW now has an error callback, which can provide your application with much
more detailed diagnostics than was previously possible. The callback is passed
an error code and a description string.
@subsubsection news_30_wndptr Per-window user pointer
Each window now has a user-defined pointer, retrieved with @ref
glfwGetWindowUserPointer and set with @ref glfwSetWindowUserPointer, to make it
easier to integrate GLFW into C++ code.
@subsubsection news_30_iconifyfun Window iconification callback
Each window now has a callback for iconification and restoration events,
which is set with @ref glfwSetWindowIconifyCallback.
@subsubsection news_30_wndposfun Window position callback
Each window now has a callback for position events, which is set with @ref
glfwSetWindowPosCallback.
@subsubsection news_30_wndpos Window position query
The position of a window can now be retrieved using @ref glfwGetWindowPos.
@subsubsection news_30_focusfun Window focus callback
Each windows now has a callback for focus events, which is set with @ref
glfwSetWindowFocusCallback.
@subsubsection news_30_enterleave Cursor enter/leave callback
Each window now has a callback for when the mouse cursor enters or leaves its
content area, which is set with @ref glfwSetCursorEnterCallback.
@subsubsection news_30_wndtitle Initial window title
The title of a window is now specified at creation time, as one of the arguments
to @ref glfwCreateWindow.
@subsubsection news_30_hidden Hidden windows
Windows can now be hidden with @ref glfwHideWindow, shown using @ref
glfwShowWindow and created initially hidden with the @ref GLFW_VISIBLE window
hint and attribute. This allows for off-screen rendering in a way compatible
with most drivers, as well as moving a window to a specific position before
showing it.
@subsubsection news_30_undecorated Undecorated windows
Windowed mode windows can now be created without decorations, e.g. things like
a frame, a title bar, with the @ref GLFW_DECORATED window hint and attribute.
This allows for the creation of things like splash screens.
@subsubsection news_30_keymods Modifier key bit masks
[Modifier key bit mask](@ref mods) parameters have been added to the
[mouse button](@ref GLFWmousebuttonfun) and [key](@ref GLFWkeyfun) callbacks.
@subsubsection news_30_scancode Platform-specific scancodes
A scancode parameter has been added to the [key callback](@ref GLFWkeyfun). Keys
that don't have a [key token](@ref keys) still get passed on with the key
parameter set to `GLFW_KEY_UNKNOWN`. These scancodes will vary between machines
and are intended to be used for key bindings.
@subsubsection news_30_jsname Joystick names
The name of a joystick can now be retrieved using @ref glfwGetJoystickName.
@subsubsection news_30_doxygen Doxygen documentation
You are reading it.
*/

402
deps/glfw/docs/news.md vendored Normal file
View File

@ -0,0 +1,402 @@
# Release notes for version 3.4 {#news}
[TOC]
## New features {#features}
### Runtime platform selection {#runtime_platform_selection}
GLFW now supports being compiled for multiple backends and selecting between
them at runtime with the @ref GLFW_PLATFORM init hint. After initialization the
selected platform can be queried with @ref glfwGetPlatform. You can check if
support for a given platform is compiled in with @ref glfwPlatformSupported.
For more information see @ref platform.
### More standard cursor shapes {#more_cursor_shapes}
GLFW now provides the standard cursor shapes @ref GLFW_RESIZE_NWSE_CURSOR and
@ref GLFW_RESIZE_NESW_CURSOR for diagonal resizing, @ref GLFW_RESIZE_ALL_CURSOR
for omnidirectional resizing and @ref GLFW_NOT_ALLOWED_CURSOR for showing an
action is not allowed.
Unlike the original set, these shapes may not be available everywhere and
creation will then fail with the new @ref GLFW_CURSOR_UNAVAILABLE error.
The cursors for horizontal and vertical resizing are now referred to as @ref
GLFW_RESIZE_EW_CURSOR and @ref GLFW_RESIZE_NS_CURSOR, and the pointing hand
cursor is now referred to as @ref GLFW_POINTING_HAND_CURSOR. The older names
are still available.
For more information see @ref cursor_standard.
### Mouse event passthrough {#mouse_input_passthrough}
GLFW now provides the [GLFW_MOUSE_PASSTHROUGH](@ref GLFW_MOUSE_PASSTHROUGH_hint)
window hint for making a window transparent to mouse input, lettings events pass
to whatever window is behind it. This can also be changed after window
creation with the matching [window attribute](@ref GLFW_MOUSE_PASSTHROUGH_attrib).
### Ability to get window title {#window_title_function}
GLFW now supports querying the title of a window with the @ref glfwGetWindowTitle
function.
For more information see @ref window_title.
### Captured cursor mode {#captured_cursor_mode}
GLFW now supports confining the cursor to the window content area with the @ref
GLFW_CURSOR_CAPTURED cursor mode.
For more information see @ref cursor_mode.
### Support for custom heap memory allocator {#custom_heap_allocator}
GLFW now supports plugging a custom heap memory allocator at initialization with
@ref glfwInitAllocator. The allocator is a struct of type @ref GLFWallocator
with function pointers corresponding to the standard library functions `malloc`,
`realloc` and `free`.
For more information see @ref init_allocator.
### Window hint for framebuffer scaling {#scale_framebuffer_hint}
GLFW now allows provides the
[GLFW_SCALE_FRAMEBUFFER](@ref GLFW_SCALE_FRAMEBUFFER_hint) window hint for
controlling framebuffer scaling on platforms that handle scaling by keeping the
window size the same while resizing the framebuffer. The default value is to
allow framebuffer scaling.
This was already possible on macOS via the
[GLFW_COCOA_RETINA_FRAMEBUFFER](@ref GLFW_COCOA_RETINA_FRAMEBUFFER_hint) window
hint. This is now another name for the same hint value.
For more information see @ref window_scale.
### Window hints for initial window position {#window_position_hint}
GLFW now provides the @ref GLFW_POSITION_X and @ref GLFW_POSITION_Y window hints for
specifying the initial position of the window. This removes the need to create a hidden
window, move it and then show it. The default value of these hints is
`GLFW_ANY_POSITION`, which selects the previous behavior.
For more information see @ref window_pos.
### ANGLE rendering backend hint {#angle_renderer_hint}
GLFW now provides the
[GLFW_ANGLE_PLATFORM_TYPE](@ref GLFW_ANGLE_PLATFORM_TYPE_hint) init hint for
requesting a specific rendering backend when using [ANGLE][] to create OpenGL ES
contexts.
[ANGLE]: https://chromium.googlesource.com/angle/angle/
### Windows window menu keyboard access hint {#win32_keymenu_hint}
GLFW now provides the
[GLFW_WIN32_KEYBOARD_MENU](@ref GLFW_WIN32_KEYBOARD_MENU_hint) window hint for
enabling keyboard access to the window menu via the Alt+Space and
Alt-and-then-Space shortcuts. This may be useful for more GUI-oriented
applications.
### Windows STARTUPINFO show command hint {#win32_showdefault_hint}
GLFW now provides the [GLFW_WIN32_SHOWDEFAULT](@ref GLFW_WIN32_SHOWDEFAULT_hint) window
hint for applying the show command in the program's `STARTUPINFO` when showing the window
for the first time. This may be useful for the main window of a windowed-mode tool.
### Cocoa NSView native access function {#cocoa_nsview_function}
GLFW now provides the @ref glfwGetCocoaView native access function
for returning the Cocoa NSView.
### Wayland libdecor decorations {#wayland_libdecor_decorations}
GLFW now supports improved client-side window decorations via
[libdecor](https://gitlab.freedesktop.org/libdecor/libdecor). This provides
fully featured window decorations on desktop environments like GNOME.
Support for libdecor can be toggled before GLFW is initialized with the
[GLFW_WAYLAND_LIBDECOR](@ref GLFW_WAYLAND_LIBDECOR_hint) init hint. It is
enabled by default.
This feature has also been available in GLFW 3.3 since 3.3.9.
### Wayland surface app_id hint {#wayland_app_id_hint}
GLFW now supports specifying the app_id for a Wayland window using the
[GLFW_WAYLAND_APP_ID](@ref GLFW_WAYLAND_APP_ID_hint) window hint string.
### X11 Vulkan window surface hint {#x11_xcb_vulkan_surface}
GLFW now supports disabling the use of `VK_KHR_xcb_surface` over
`VK_KHR_xlib_surface` where available, with the
[GLFW_X11_XCB_VULKAN_SURFACE](@ref GLFW_X11_XCB_VULKAN_SURFACE_hint) init hint.
This affects @ref glfwGetRequiredInstanceExtensions and @ref
glfwCreateWindowSurface.
## Caveats {#caveats}
### Multiple sets of native access functions {#multiplatform_caveat}
Because GLFW now supports runtime selection of platform (window system), a library binary
may export native access functions for multiple platforms. Starting with version 3.4 you
must not assume that GLFW is running on a platform just because it exports native access
functions for it. After initialization, you can query the selected platform with @ref
glfwGetPlatform.
### Version string format has been changed {#version_string_caveat}
Because GLFW now supports runtime selection of platform (window system), the version
string returned by @ref glfwGetVersionString has been expanded. It now contains the names
of all APIs for all the platforms that the library binary supports.
The version string is intended for bug reporting and should not be parsed. See
@ref glfwGetVersion and @ref glfwPlatformSupported instead.
### Joystick support is initialized on demand {#joystick_init_caveat}
The joystick part of GLFW is now initialized when first used, primarily to work
around faulty Windows drivers that cause DirectInput to take up to several
seconds to enumerate devices.
This change is mostly not observable. However, if your application waits for
events without having first called any joystick function or created any visible
windows, the wait may never unblock as GLFW may not yet have subscribed to
joystick related OS events.
To work around this, call any joystick function before waiting for events, for
example by setting a [joystick callback](@ref joystick_event).
### Tests and examples are disabled when built as a subproject {#standalone_caveat}
GLFW now by default does not build the tests or examples when it is added as
a subdirectory of another CMake project. If you were setting @ref
GLFW_BUILD_TESTS or @ref GLFW_BUILD_EXAMPLES to false in your CMake files, you
can now remove this.
If you do want these to be built, set @ref GLFW_BUILD_TESTS and @ref
GLFW_BUILD_EXAMPLES in your CMake files before adding the GLFW subdirectory.
```cmake
set(GLFW_BUILD_EXAMPLES ON CACHE BOOL "" FORCE)
set(GLFW_BUILD_TESTS ON CACHE BOOL "" FORCE)
add_subdirectory(path/to/glfw)
```
### Configuration header is no longer generated {#config_header_caveat}
The `glfw_config.h` configuration header is no longer generated by CMake and the
platform selection macros are now part of the GLFW CMake target. The
`_GLFW_USE_CONFIG_H` macro is still supported in case you are generating
a configuration header in a custom build setup.
### Documentation generation requires Doxygen 1.9.8 or later {#docs_target_caveat}
Doxygen 1.9.8 or later is now required for the `docs` CMake target to be
generated. This is because the documentation now uses more of the Markdown
support in Doxygen and this support has until recently been relatively unstable.
### Windows 7 framebuffer transparency requires DWM transparency {#win7_framebuffer_caveat}
GLFW no longer supports per-pixel framebuffer transparency via @ref
GLFW_TRANSPARENT_FRAMEBUFFER on Windows 7 if DWM transparency is off
(the Transparency setting under Personalization > Window Color).
### macOS main menu now created at initialization {#macos_menu_caveat}
GLFW now creates the main menu and completes the initialization of NSApplication
during initialization. Programs that do not want a main menu can disable it
with the [GLFW_COCOA_MENUBAR](@ref GLFW_COCOA_MENUBAR_hint) init hint.
### macOS CoreVideo dependency has been removed {#corevideo_caveat}
GLFW no longer depends on the CoreVideo framework on macOS and it no longer
needs to be specified during compilation or linking.
### Wayland framebuffer may lack alpha channel on older systems {#wayland_alpha_caveat}
On Wayland, when creating an EGL context on a machine lacking the new
`EGL_EXT_present_opaque` extension, the @ref GLFW_ALPHA_BITS window hint will be
ignored and the framebuffer will not have an alpha channel. This is because
some Wayland compositors treat any buffer with an alpha channel as per-pixel
transparent.
If you want a per-pixel transparent window, see the
[GLFW_TRANSPARENT_FRAMEBUFFER](@ref GLFW_TRANSPARENT_FRAMEBUFFER_hint) window
hint.
### X11 empty events no longer round-trip to server {#x11_emptyevent_caveat}
Events posted with @ref glfwPostEmptyEvent now use a separate unnamed pipe
instead of sending an X11 client event to the helper window.
## Deprecations {#deprecations}
### Windows XP and Vista support is deprecated {#winxp_deprecated}
Support for Windows XP and Vista has been deprecated and will be removed in
a future release. Windows XP has been out of extended support since 2014.
### Original MinGW support is deprecated {#mingw_deprecated}
Support for the now unmaintained original MinGW distribution has been deprecated
and will be removed in a future release.
This does not apply to the much more capable MinGW-w64, which remains fully
supported, actively maintained and available on many platforms.
### OS X Yosemite support is deprecated {#yosemite_deprecated}
Support for OS X 10.10 Yosemite and earlier has been deprecated and will be
removed in a future release. OS X 10.10 has been out of support since 2017.
## Removals {#removals}
### GLFW_VULKAN_STATIC CMake option has been removed {#vulkan_static_removed}
This option was used to compile GLFW directly linked with the Vulkan loader, instead of
using dynamic loading to get hold of `vkGetInstanceProcAddr` at initialization. This is
now done by calling the @ref glfwInitVulkanLoader function before initialization.
If you need backward compatibility, this macro can still be defined for GLFW 3.4 and will
have no effect. The call to @ref glfwInitVulkanLoader can be conditionally enabled in
your code by checking the @ref GLFW_VERSION_MAJOR and @ref GLFW_VERSION_MINOR macros.
### GLFW_USE_WAYLAND CMake option has been removed {#use_wayland_removed}
This option was used to compile GLFW for Wayland instead of X11. GLFW now
supports selecting the platform at run-time. By default GLFW is compiled for
both Wayland and X11 on Linux and other Unix-like systems.
To disable Wayland or X11 or both, set the @ref GLFW_BUILD_WAYLAND and @ref
GLFW_BUILD_X11 CMake options.
The `GLFW_USE_WAYLAND` CMake variable must not be present in the CMake cache at
all, or GLFW will fail to configure. If you are getting this error, delete the
CMake cache for GLFW and configure again.
### GLFW_USE_OSMESA CMake option has been removed {#use_osmesa_removed}
This option was used to compile GLFW for the Null platform. The Null platform
is now always available. To produce a library binary that only supports this
platform, the way this CMake option used to do, you will instead need to disable
the default platforms for the target OS. This means setting the @ref
GLFW_BUILD_WIN32, @ref GLFW_BUILD_COCOA or @ref GLFW_BUILD_WAYLAND and @ref
GLFW_BUILD_X11 CMake options to false.
You can set all of them to false and the ones that don't apply for the target OS
will be ignored.
### wl_shell protocol support has been removed {#wl_shell_removed}
Support for the deprecated wl_shell protocol has been removed and GLFW now only
supports the XDG-Shell protocol. If your Wayland compositor does not support
XDG-Shell then GLFW will fail to initialize.
## New symbols {#new_symbols}
### New functions {#new_functions}
- @ref glfwInitAllocator
- @ref glfwGetPlatform
- @ref glfwPlatformSupported
- @ref glfwInitVulkanLoader
- @ref glfwGetWindowTitle
- @ref glfwGetCocoaView
### New types {#new_types}
- @ref GLFWallocator
- @ref GLFWallocatefun
- @ref GLFWreallocatefun
- @ref GLFWdeallocatefun
### New constants {#new_constants}
- @ref GLFW_PLATFORM
- @ref GLFW_ANY_PLATFORM
- @ref GLFW_PLATFORM_WIN32
- @ref GLFW_PLATFORM_COCOA
- @ref GLFW_PLATFORM_WAYLAND
- @ref GLFW_PLATFORM_X11
- @ref GLFW_PLATFORM_NULL
- @ref GLFW_PLATFORM_UNAVAILABLE
- @ref GLFW_POINTING_HAND_CURSOR
- @ref GLFW_RESIZE_EW_CURSOR
- @ref GLFW_RESIZE_NS_CURSOR
- @ref GLFW_RESIZE_NWSE_CURSOR
- @ref GLFW_RESIZE_NESW_CURSOR
- @ref GLFW_RESIZE_ALL_CURSOR
- @ref GLFW_MOUSE_PASSTHROUGH
- @ref GLFW_NOT_ALLOWED_CURSOR
- @ref GLFW_CURSOR_UNAVAILABLE
- @ref GLFW_WIN32_KEYBOARD_MENU
- @ref GLFW_WIN32_SHOWDEFAULT
- @ref GLFW_CONTEXT_DEBUG
- @ref GLFW_FEATURE_UNAVAILABLE
- @ref GLFW_FEATURE_UNIMPLEMENTED
- @ref GLFW_ANGLE_PLATFORM_TYPE
- @ref GLFW_ANGLE_PLATFORM_TYPE_NONE
- @ref GLFW_ANGLE_PLATFORM_TYPE_OPENGL
- @ref GLFW_ANGLE_PLATFORM_TYPE_OPENGLES
- @ref GLFW_ANGLE_PLATFORM_TYPE_D3D9
- @ref GLFW_ANGLE_PLATFORM_TYPE_D3D11
- @ref GLFW_ANGLE_PLATFORM_TYPE_VULKAN
- @ref GLFW_ANGLE_PLATFORM_TYPE_METAL
- @ref GLFW_X11_XCB_VULKAN_SURFACE
- @ref GLFW_CURSOR_CAPTURED
- @ref GLFW_POSITION_X
- @ref GLFW_POSITION_Y
- @ref GLFW_ANY_POSITION
- @ref GLFW_WAYLAND_APP_ID
- @ref GLFW_WAYLAND_LIBDECOR
- @ref GLFW_WAYLAND_PREFER_LIBDECOR
- @ref GLFW_WAYLAND_DISABLE_LIBDECOR
- @ref GLFW_SCALE_FRAMEBUFFER
## Release notes for earlier versions {#news_archive}
- [Release notes for 3.3](https://www.glfw.org/docs/3.3/news.html)
- [Release notes for 3.2](https://www.glfw.org/docs/3.2/news.html)
- [Release notes for 3.1](https://www.glfw.org/docs/3.1/news.html)
- [Release notes for 3.0](https://www.glfw.org/docs/3.0/news.html)

146
deps/glfw/docs/quick.dox → deps/glfw/docs/quick.md vendored
View File

@ -1,10 +1,8 @@
/*!
# Getting started {#quick_guide}
@page quick_guide Getting started
[TOC]
@tableofcontents
This guide takes you through writing a simple application using GLFW 3. The
This guide takes you through writing a small application using GLFW 3. The
application will create a window and OpenGL context, render a rotating triangle
and exit when the user closes the window or presses _Escape_. This guide will
introduce a few of the most commonly used functions, but there are many more.
@ -14,16 +12,16 @@ have used GLFW 2 in the past, read @ref moving_guide, as some functions
behave differently in GLFW 3.
@section quick_steps Step by step
## Step by step {#quick_steps}
@subsection quick_include Including the GLFW header
### Including the GLFW header {#quick_include}
In the source files of your application where you use GLFW, you need to include
its header file.
@code
```c
#include <GLFW/glfw3.h>
@endcode
```
This header provides all the constants, types and function prototypes of the
GLFW API.
@ -38,51 +36,51 @@ This example uses files generated by [glad](https://gen.glad.sh/). The GLFW
header can detect most such headers if they are included first and will then not
include the one from your development environment.
@code
```c
#include <glad/gl.h>
#include <GLFW/glfw3.h>
@endcode
```
To make sure there will be no header conflicts, you can define @ref
GLFW_INCLUDE_NONE before the GLFW header to explicitly disable inclusion of the
development environment header. This also allows the two headers to be included
in any order.
@code
```c
#define GLFW_INCLUDE_NONE
#include <GLFW/glfw3.h>
#include <glad/gl.h>
@endcode
```
@subsection quick_init_term Initializing and terminating GLFW
### Initializing and terminating GLFW {#quick_init_term}
Before you can use most GLFW functions, the library must be initialized. On
successful initialization, `GLFW_TRUE` is returned. If an error occurred,
`GLFW_FALSE` is returned.
@code
```c
if (!glfwInit())
{
// Initialization failed
}
@endcode
```
Note that `GLFW_TRUE` and `GLFW_FALSE` are and will always be one and zero.
When you are done using GLFW, typically just before the application exits, you
need to terminate GLFW.
@code
```c
glfwTerminate();
@endcode
```
This destroys any remaining windows and releases any other resources allocated by
GLFW. After this call, you must initialize GLFW again before using any GLFW
functions that require it.
@subsection quick_capture_error Setting an error callback
### Setting an error callback {#quick_capture_error}
Most events are reported through callbacks, whether it's a key being pressed,
a GLFW window being moved, or an error occurring. Callbacks are C functions (or
@ -92,36 +90,36 @@ In case a GLFW function fails, an error is reported to the GLFW error callback.
You can receive these reports with an error callback. This function must have
the signature below but may do anything permitted in other callbacks.
@code
```c
void error_callback(int error, const char* description)
{
fprintf(stderr, "Error: %s\n", description);
}
@endcode
```
Callback functions must be set, so GLFW knows to call them. The function to set
the error callback is one of the few GLFW functions that may be called before
initialization, which lets you be notified of errors both during and after
initialization.
@code
```c
glfwSetErrorCallback(error_callback);
@endcode
```
@subsection quick_create_window Creating a window and context
### Creating a window and context {#quick_create_window}
The window and its OpenGL context are created with a single call to @ref
glfwCreateWindow, which returns a handle to the created combined window and
context object
@code
```c
GLFWwindow* window = glfwCreateWindow(640, 480, "My Title", NULL, NULL);
if (!window)
{
// Window or OpenGL context creation failed
}
@endcode
```
This creates a 640 by 480 windowed mode window with an OpenGL context. If
window or OpenGL context creation fails, `NULL` will be returned. You should
@ -134,37 +132,38 @@ require a minimum OpenGL version by setting the `GLFW_CONTEXT_VERSION_MAJOR` and
`GLFW_CONTEXT_VERSION_MINOR` hints _before_ creation. If the required minimum
version is not supported on the machine, context (and window) creation fails.
@code
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 2);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 0);
You can select the OpenGL profile by setting the `GLFW_OPENGL_PROFILE` hint.
This program uses the core profile as that is the only profile macOS supports
for OpenGL 3.x and 4.x.
```c
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
GLFWwindow* window = glfwCreateWindow(640, 480, "My Title", NULL, NULL);
if (!window)
{
// Window or context creation failed
}
@endcode
The window handle is passed to all window related functions and is provided to
along to all window related callbacks, so they can tell which window received
the event.
```
When a window and context is no longer needed, destroy it.
@code
```c
glfwDestroyWindow(window);
@endcode
```
Once this function is called, no more events will be delivered for that window
and its handle becomes invalid.
@subsection quick_context_current Making the OpenGL context current
### Making the OpenGL context current {#quick_context_current}
Before you can use the OpenGL API, you must have a current OpenGL context.
@code
```c
glfwMakeContextCurrent(window);
@endcode
```
The context will remain current until you make another context current or until
the window owning the current context is destroyed.
@ -175,12 +174,12 @@ a current context to load from. This example uses
[glad](https://github.com/Dav1dde/glad), but the same rule applies to all such
libraries.
@code
```c
gladLoadGL(glfwGetProcAddress);
@endcode
```
@subsection quick_window_close Checking the window close flag
### Checking the window close flag {#quick_window_close}
Each window has a flag indicating whether the window should be closed.
@ -190,12 +189,12 @@ Note that __the window isn't actually closed__, so you are expected to monitor
this flag and either destroy the window or give some kind of feedback to the
user.
@code
```c
while (!glfwWindowShouldClose(window))
{
// Keep running
}
@endcode
```
You can be notified when the user is attempting to close the window by setting
a close callback with @ref glfwSetWindowCloseCallback. The callback will be
@ -206,41 +205,41 @@ useful if you want to interpret other kinds of input as closing the window, like
for example pressing the _Escape_ key.
@subsection quick_key_input Receiving input events
### Receiving input events {#quick_key_input}
Each window has a large number of callbacks that can be set to receive all the
various kinds of events. To receive key press and release events, create a key
callback function.
@code
```c
static void key_callback(GLFWwindow* window, int key, int scancode, int action, int mods)
{
if (key == GLFW_KEY_ESCAPE && action == GLFW_PRESS)
glfwSetWindowShouldClose(window, GLFW_TRUE);
}
@endcode
```
The key callback, like other window related callbacks, are set per-window.
@code
```c
glfwSetKeyCallback(window, key_callback);
@endcode
```
In order for event callbacks to be called when events occur, you need to process
events as described below.
@subsection quick_render Rendering with OpenGL
### Rendering with OpenGL {#quick_render}
Once you have a current OpenGL context, you can use OpenGL normally. In this
tutorial, a multi-colored rotating triangle will be rendered. The framebuffer
tutorial, a multicolored rotating triangle will be rendered. The framebuffer
size needs to be retrieved for `glViewport`.
@code
```c
int width, height;
glfwGetFramebufferSize(window, &width, &height);
glViewport(0, 0, width, height);
@endcode
```
You can also set a framebuffer size callback using @ref
glfwSetFramebufferSizeCallback and be notified when the size changes.
@ -257,19 +256,19 @@ These all happen to use GLFW, but OpenGL itself works the same whatever API you
use to create the window and context.
@subsection quick_timer Reading the timer
### Reading the timer {#quick_timer}
To create smooth animation, a time source is needed. GLFW provides a timer that
returns the number of seconds since initialization. The time source used is the
most accurate on each platform and generally has micro- or nanosecond
resolution.
@code
```c
double time = glfwGetTime();
@endcode
```
@subsection quick_swap_buffers Swapping buffers
### Swapping buffers {#quick_swap_buffers}
GLFW windows by default use double buffering. That means that each window has
two rendering buffers; a front buffer and a back buffer. The front buffer is
@ -278,9 +277,9 @@ the one being displayed and the back buffer the one you render to.
When the entire frame has been rendered, the buffers need to be swapped with one
another, so the back buffer becomes the front buffer and vice versa.
@code
```c
glfwSwapBuffers(window);
@endcode
```
The swap interval indicates how many frames to wait until swapping the buffers,
commonly known as _vsync_. By default, the swap interval is zero, meaning
@ -295,15 +294,15 @@ For these reasons, applications will typically want to set the swap interval to
one. It can be set to higher values, but this is usually not recommended,
because of the input latency it leads to.
@code
```c
glfwSwapInterval(1);
@endcode
```
This function acts on the current context and will fail unless a context is
current.
@subsection quick_process_events Processing events
### Processing events {#quick_process_events}
GLFW needs to communicate regularly with the window system both in order to
receive events and to show that the application hasn't locked up. Event
@ -314,9 +313,9 @@ There are two methods for processing pending events; polling and waiting. This
example will use event polling, which processes only those events that have
already been received and then returns immediately.
@code
```c
glfwPollEvents();
@endcode
```
This is the best choice when rendering continually, like most games do. If
instead you only need to update your rendering once you have received new input,
@ -326,22 +325,24 @@ all received events. This saves a great deal of CPU cycles and is useful for,
for example, many kinds of editing tools.
@section quick_example Putting it together
## Putting it together {#quick_example}
Now that you know how to initialize GLFW, create a window and poll for
keyboard input, it's possible to create a simple program.
keyboard input, it's possible to create a small program.
This program creates a 640 by 480 windowed mode window and starts a loop that
clears the screen, renders a triangle and processes events until the user either
presses _Escape_ or closes the window.
@snippet simple.c code
@snippet triangle-opengl.c code
The program above can be found in the
[source package](https://www.glfw.org/download.html) as `examples/simple.c`
and is compiled along with all other examples when you build GLFW. If you
built GLFW from the source package then you already have this as `simple.exe` on
Windows, `simple` on Linux or `simple.app` on macOS.
The program above can be found in the [source package][download] as
`examples/triangle-opengl.c` and is compiled along with all other examples when
you build GLFW. If you built GLFW from the source package then you already have
this as `triangle-opengl.exe` on Windows, `triangle-opengl` on Linux or
`triangle-opengl.app` on macOS.
[download]: https://www.glfw.org/download.html
This tutorial used only a few of the many functions GLFW provides. There are
guides for each of the areas covered by GLFW. Each guide will introduce all the
@ -362,4 +363,3 @@ environment you are using and is best explained by the documentation for that
environment. To learn about the details that are specific to GLFW, see
@ref build_guide.
*/

117
deps/glfw/docs/vulkan.dox → deps/glfw/docs/vulkan.md vendored
View File

@ -1,8 +1,6 @@
/*!
# Vulkan guide {#vulkan_guide}
@page vulkan_guide Vulkan guide
@tableofcontents
[TOC]
This guide is intended to fill the gaps between the official [Vulkan
resources](https://www.khronos.org/vulkan/) and the rest of the GLFW
@ -29,51 +27,62 @@ are also guides for the other areas of the GLFW API.
- @ref input_guide
@section vulkan_loader Linking against the Vulkan loader
## Finding the Vulkan loader {#vulkan_loader}
By default, GLFW will look for the Vulkan loader on demand at runtime via its
standard name (`vulkan-1.dll` on Windows, `libvulkan.so.1` on Linux and other
Unix-like systems and `libvulkan.1.dylib` on macOS). This means that GLFW does
not need to be linked against the loader. However, it also means that if you
are using the static library form of the Vulkan loader GLFW will either fail to
find it or (worse) use the wrong one.
GLFW itself does not ever need to be linked against the Vulkan loader.
The @ref GLFW_VULKAN_STATIC CMake option makes GLFW call the Vulkan loader
directly instead of dynamically loading it at runtime. Not linking against the
Vulkan loader will then be a compile-time error.
By default, GLFW will load the Vulkan loader dynamically at runtime via its standard name:
`vulkan-1.dll` on Windows, `libvulkan.so.1` on Linux and other Unix-like systems and
`libvulkan.1.dylib` on macOS.
@macos Because the Vulkan loader and ICD are not installed globally on macOS,
you need to set up the application bundle according to the LunarG SDK
documentation. This is explained in more detail in the
@macos GLFW will also look up and search the `Frameworks` subdirectory of your
application bundle.
If your code is using a Vulkan loader with a different name or in a non-standard location
you will need to direct GLFW to it. Pass your version of `vkGetInstanceProcAddr` to @ref
glfwInitVulkanLoader before initializing GLFW and it will use that function for all Vulkan
entry point retrieval. This prevents GLFW from dynamically loading the Vulkan loader.
```c
glfwInitVulkanLoader(vkGetInstanceProcAddr);
```
@macos To make your application be redistributable you will need to set up the application
bundle according to the LunarG SDK documentation. This is explained in more detail in the
[SDK documentation for macOS](https://vulkan.lunarg.com/doc/sdk/latest/mac/getting_started.html).
@section vulkan_include Including the Vulkan and GLFW header files
## Including the Vulkan header file {#vulkan_include}
To include the Vulkan header, define @ref GLFW_INCLUDE_VULKAN before including
To have GLFW include the Vulkan header, define @ref GLFW_INCLUDE_VULKAN before including
the GLFW header.
@code
```c
#define GLFW_INCLUDE_VULKAN
#include <GLFW/glfw3.h>
@endcode
```
If you instead want to include the Vulkan header from a custom location or use
your own custom Vulkan header then do this before the GLFW header.
@code
```c
#include <path/to/vulkan.h>
#include <GLFW/glfw3.h>
@endcode
```
Unless a Vulkan header is included, either by the GLFW header or above it, any
GLFW functions that take or return Vulkan types will not be declared.
Unless a Vulkan header is included, either by the GLFW header or above it, the following
GLFW functions will not be declared, as depend on Vulkan types.
- @ref glfwInitVulkanLoader
- @ref glfwGetInstanceProcAddress
- @ref glfwGetPhysicalDevicePresentationSupport
- @ref glfwCreateWindowSurface
The `VK_USE_PLATFORM_*_KHR` macros do not need to be defined for the Vulkan part
of GLFW to work. Define them only if you are using these extensions directly.
@section vulkan_support Querying for Vulkan support
## Querying for Vulkan support {#vulkan_support}
If you are linking directly against the Vulkan loader then you can skip this
section. The canonical desktop loader library exports all Vulkan core and
@ -83,12 +92,12 @@ If you are loading the Vulkan loader dynamically instead of linking directly
against it, you can check for the availability of a loader and ICD with @ref
glfwVulkanSupported.
@code
```c
if (glfwVulkanSupported())
{
// Vulkan is available, at least for compute
}
@endcode
```
This function returns `GLFW_TRUE` if the Vulkan loader and any minimally
functional ICD was found.
@ -97,24 +106,24 @@ If one or both were not found, calling any other Vulkan related GLFW function
will generate a @ref GLFW_API_UNAVAILABLE error.
@subsection vulkan_proc Querying Vulkan function pointers
### Querying Vulkan function pointers {#vulkan_proc}
To load any Vulkan core or extension function from the found loader, call @ref
glfwGetInstanceProcAddress. To load functions needed for instance creation,
pass `NULL` as the instance.
@code
```c
PFN_vkCreateInstance pfnCreateInstance = (PFN_vkCreateInstance)
glfwGetInstanceProcAddress(NULL, "vkCreateInstance");
@endcode
```
Once you have created an instance, you can load from it all other Vulkan core
functions and functions from any instance extensions you enabled.
@code
```c
PFN_vkCreateDevice pfnCreateDevice = (PFN_vkCreateDevice)
glfwGetInstanceProcAddress(instance, "vkCreateDevice");
@endcode
```
This function in turn calls `vkGetInstanceProcAddr`. If that fails, the
function falls back to a platform-specific query of the Vulkan loader (i.e.
@ -126,17 +135,17 @@ Vulkan also provides `vkGetDeviceProcAddr` for loading device-specific versions
of Vulkan function. This function can be retrieved from an instance with @ref
glfwGetInstanceProcAddress.
@code
```c
PFN_vkGetDeviceProcAddr pfnGetDeviceProcAddr = (PFN_vkGetDeviceProcAddr)
glfwGetInstanceProcAddress(instance, "vkGetDeviceProcAddr");
@endcode
```
Device-specific functions may execute a little bit faster, due to not having to
Device-specific functions may execute a little faster, due to not having to
dispatch internally based on the device passed to them. For more information
about `vkGetDeviceProcAddr`, see the Vulkan documentation.
@section vulkan_ext Querying required Vulkan extensions
## Querying required Vulkan extensions {#vulkan_ext}
To do anything useful with Vulkan you need to create an instance. If you want
to use Vulkan to render to a window, you must enable the instance extensions
@ -145,10 +154,10 @@ GLFW requires to create Vulkan surfaces.
To query the instance extensions required, call @ref
glfwGetRequiredInstanceExtensions.
@code
```c
uint32_t count;
const char** extensions = glfwGetRequiredInstanceExtensions(&count);
@endcode
```
These extensions must all be enabled when creating instances that are going to
be passed to @ref glfwGetPhysicalDevicePresentationSupport and @ref
@ -163,67 +172,74 @@ If successful the returned array will always include `VK_KHR_surface`, so if
you don't require any additional extensions you can pass this list directly to
the `VkInstanceCreateInfo` struct.
@code
```c
VkInstanceCreateInfo ici;
memset(&ici, 0, sizeof(ici));
ici.enabledExtensionCount = count;
ici.ppEnabledExtensionNames = extensions;
...
@endcode
```
Additional extensions may be required by future versions of GLFW. You should
check whether any extensions you wish to enable are already in the returned
array, as it is an error to specify an extension more than once in the
`VkInstanceCreateInfo` struct.
@macos MoltenVK is (as of July 2022) not yet a fully conformant implementation
of Vulkan. As of Vulkan SDK 1.3.216.0, this means you must also enable the
`VK_KHR_portability_enumeration` instance extension and set the
`VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR` bit in the instance creation
info flags for MoltenVK to show up in the list of physical devices. For more
information, see the Vulkan and MoltenVK documentation.
@section vulkan_present Querying for Vulkan presentation support
## Querying for Vulkan presentation support {#vulkan_present}
Not every queue family of every Vulkan device can present images to surfaces.
To check whether a specific queue family of a physical device supports image
presentation without first having to create a window and surface, call @ref
glfwGetPhysicalDevicePresentationSupport.
@code
```c
if (glfwGetPhysicalDevicePresentationSupport(instance, physical_device, queue_family_index))
{
// Queue family supports image presentation
}
@endcode
```
The `VK_KHR_surface` extension additionally provides the
`vkGetPhysicalDeviceSurfaceSupportKHR` function, which performs the same test on
an existing Vulkan surface.
@section vulkan_window Creating the window
## Creating the window {#vulkan_window}
Unless you will be using OpenGL or OpenGL ES with the same window as Vulkan,
there is no need to create a context. You can disable context creation with the
[GLFW_CLIENT_API](@ref GLFW_CLIENT_API_hint) hint.
@code
```c
glfwWindowHint(GLFW_CLIENT_API, GLFW_NO_API);
GLFWwindow* window = glfwCreateWindow(640, 480, "Window Title", NULL, NULL);
@endcode
```
See @ref context_less for more information.
@section vulkan_surface Creating a Vulkan window surface
## Creating a Vulkan window surface {#vulkan_surface}
You can create a Vulkan surface (as defined by the `VK_KHR_surface` extension)
for a GLFW window with @ref glfwCreateWindowSurface.
@code
```c
VkSurfaceKHR surface;
VkResult err = glfwCreateWindowSurface(instance, window, NULL, &surface);
if (err)
{
// Window surface creation failed
}
@endcode
```
If an OpenGL or OpenGL ES context was created on the window, the context has
ownership of the presentation on the window and a Vulkan surface cannot be
@ -232,4 +248,3 @@ created.
It is your responsibility to destroy the surface. GLFW does not destroy it for
you. Call `vkDestroySurfaceKHR` function from the same extension to destroy it.
*/

552
deps/glfw/docs/window.dox → deps/glfw/docs/window.md vendored
View File

File diff suppressed because it is too large Load Diff