From df15a33e1035d47c223e83ecd4018e392c851969 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Camilla=20L=C3=B6wy?= Date: Mon, 7 Jun 2021 22:34:33 +0200 Subject: [PATCH 01/18] Fix numeric conversion warnings in example --- examples/heightmap.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/examples/heightmap.c b/examples/heightmap.c index 13a3c1e1..988dd0b8 100644 --- a/examples/heightmap.c +++ b/examples/heightmap.c @@ -292,12 +292,12 @@ static void generate_heightmap__circle(float* center_x, float* center_y, { float sign; /* random value for element in between [0-1.0] */ - *center_x = (MAP_SIZE * rand()) / (1.0f * RAND_MAX); - *center_y = (MAP_SIZE * rand()) / (1.0f * RAND_MAX); - *size = (MAX_CIRCLE_SIZE * rand()) / (1.0f * RAND_MAX); - sign = (1.0f * rand()) / (1.0f * RAND_MAX); + *center_x = (MAP_SIZE * rand()) / (float) RAND_MAX; + *center_y = (MAP_SIZE * rand()) / (float) RAND_MAX; + *size = (MAX_CIRCLE_SIZE * rand()) / (float) RAND_MAX; + sign = (1.0f * rand()) / (float) RAND_MAX; sign = (sign < DISPLACEMENT_SIGN_LIMIT) ? -1.0f : 1.0f; - *displacement = (sign * (MAX_DISPLACEMENT * rand())) / (1.0f * RAND_MAX); + *displacement = (sign * (MAX_DISPLACEMENT * rand())) / (float) RAND_MAX; } /* Run the specified number of iterations of the generation process for the From 5a6001a83be1c788e7795d891b6a9dd5931e460e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Camilla=20L=C3=B6wy?= Date: Mon, 7 Jun 2021 22:21:23 +0200 Subject: [PATCH 02/18] Migrate from Travis CI to GitHub Actions The old Travis CI .org service has been throttled for a while now and is said to be shutting down completely next week. This migrates the Travis CI build jobs to GitHub Actions, with minor changes. - The trailing whitespace detection has been removed for now. - The libegl1-mesa-dev dependency for Wayland has been removed as it appears to no longer be necessary for building. --- .github/workflows/build.yml | 91 ++++++++++++++++++++++++++++ .travis.yml | 114 ------------------------------------ README.md | 2 +- 3 files changed, 92 insertions(+), 115 deletions(-) create mode 100644 .github/workflows/build.yml delete mode 100644 .travis.yml diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml new file mode 100644 index 00000000..74b28e4a --- /dev/null +++ b/.github/workflows/build.yml @@ -0,0 +1,91 @@ +name: Build +on: + pull_request: + push: + branches: [ ci, master, 3.3-stable ] +permissions: + statuses: write + contents: read +env: + CC: clang + CFLAGS: -Werror + +jobs: + build-linux-x11-clang: + name: X11 (Linux, Clang) + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v2 + - name: Install dependencies + run: | + sudo apt update + sudo apt install libxrandr-dev libxinerama-dev libxcursor-dev libxi-dev libxext-dev + + - name: Configure static library + run: cmake -S . -B build-static + - name: Build static library + run: cmake --build build-static --parallel + + - name: Configure shared library + run: cmake -S . -B build-shared -D BUILD_SHARED_LIBS=ON + - name: Build shared library + run: cmake --build build-shared --parallel + + build-linux-wayland-clang: + name: Wayland (Linux, Clang) + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v2 + - name: Install dependencies + run: | + sudo apt update + sudo apt install wayland-protocols libwayland-dev libxkbcommon-dev + + - name: Configure static library + run: cmake -S . -B build-static -D GLFW_USE_WAYLAND=ON + - name: Build static library + run: cmake --build build-static --parallel + + - name: Configure shared library + run: cmake -S . -B build-shared -D GLFW_USE_WAYLAND=ON -D BUILD_SHARED_LIBS=ON + - name: Build shared library + run: cmake --build build-shared --parallel + + build-linux-null-clang: + name: Null (Linux, Clang) + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v2 + - name: Install dependencies + run: | + sudo apt update + sudo apt install libosmesa6-dev + + - name: Configure static library + run: cmake -S . -B build-static -D GLFW_USE_OSMESA=ON + - name: Build static library + run: cmake --build build-static --parallel + + - name: Configure shared library + run: cmake -S . -B build-shared -D GLFW_USE_OSMESA=ON -D BUILD_SHARED_LIBS=ON + - name: Build shared library + run: cmake --build build-shared --parallel + + build-macos-cocoa-clang: + name: Cocoa (macOS, Clang) + runs-on: macos-latest + env: + MACOSX_DEPLOYMENT_TARGET: 10.8 + steps: + - uses: actions/checkout@v2 + + - name: Configure static library + run: cmake -S . -B build-static + - name: Build static library + run: cmake --build build-static --parallel + + - name: Configure shared library + run: cmake -S . -B build-shared -D BUILD_SHARED_LIBS=ON + - name: Build shared library + run: cmake --build build-shared --parallel + diff --git a/.travis.yml b/.travis.yml deleted file mode 100644 index ff675629..00000000 --- a/.travis.yml +++ /dev/null @@ -1,114 +0,0 @@ -language: c -compiler: clang -branches: - only: - - ci - - master - - 3.3-stable -matrix: - include: - - os: linux - dist: xenial - name: "X11 shared library" - addons: - apt: - packages: - - libxrandr-dev - - libxinerama-dev - - libxcursor-dev - - libxi-dev - - libxext-dev - env: - - BUILD_SHARED_LIBS=ON - - CFLAGS=-Werror - - os: linux - dist: xenial - name: "X11 static library" - addons: - apt: - packages: - - libxrandr-dev - - libxinerama-dev - - libxcursor-dev - - libxi-dev - - libxext-dev - env: - - BUILD_SHARED_LIBS=OFF - - CFLAGS=-Werror - - os: linux - dist: focal - name: "Wayland shared library" - addons: - apt: - packages: - - wayland-protocols - - libwayland-dev - - libxkbcommon-dev - - libegl1-mesa-dev - env: - - USE_WAYLAND=ON - - BUILD_SHARED_LIBS=ON - - CFLAGS=-Werror - - os: linux - dist: focal - name: "Wayland static library" - addons: - apt: - packages: - - wayland-protocols - - libwayland-dev - - libxkbcommon-dev - - libegl1-mesa-dev - env: - - USE_WAYLAND=ON - - BUILD_SHARED_LIBS=OFF - - CFLAGS=-Werror - - os: linux - dist: bionic - name: "Null shared library" - addons: - apt: - packages: - - libosmesa6-dev - env: - - BUILD_SHARED_LIBS=ON - - USE_OSMESA=ON - - CFLAGS=-Werror - - os: linux - dist: bionic - name: "Null static library" - addons: - apt: - packages: - - libosmesa6-dev - env: - - BUILD_SHARED_LIBS=OFF - - USE_OSMESA=ON - - CFLAGS=-Werror - - os: osx - name: "Cocoa shared library" - env: - - BUILD_SHARED_LIBS=ON - - CFLAGS=-Werror - - MACOSX_DEPLOYMENT_TARGET=10.8 - - os: osx - name: "Cocoa static library" - env: - - BUILD_SHARED_LIBS=OFF - - CFLAGS=-Werror - - MACOSX_DEPLOYMENT_TARGET=10.8 -script: - - if grep -Inr '\s$' src include docs tests examples CMake *.md .gitattributes .gitignore; then - echo Trailing whitespace found, aborting; - exit 1; - fi - - mkdir build - - cd build - - cmake -DCMAKE_VERBOSE_MAKEFILE=ON -DBUILD_SHARED_LIBS=${BUILD_SHARED_LIBS} -DGLFW_USE_WAYLAND=${USE_WAYLAND} -DGLFW_USE_OSMESA=${USE_OSMESA} .. - - cmake --build . -notifications: - email: - recipients: - - ci@glfw.org - on_success: never - on_failure: always diff --git a/README.md b/README.md index b5b4f7ea..023d99fd 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # GLFW -[![Build status](https://travis-ci.org/glfw/glfw.svg?branch=master)](https://travis-ci.org/glfw/glfw) +[![Build status](https://github.com/glfw/glfw/actions/workflows/build.yml/badge.svg)](https://github.com/glfw/glfw/actions) [![Build status](https://ci.appveyor.com/api/projects/status/0kf0ct9831i5l6sp/branch/master?svg=true)](https://ci.appveyor.com/project/elmindreda/glfw) [![Coverity Scan](https://scan.coverity.com/projects/4884/badge.svg)](https://scan.coverity.com/projects/glfw-glfw) From 4e788fc6dc08d635aaae72ea5c804d79fe272daa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Camilla=20L=C3=B6wy?= Date: Wed, 9 Jun 2021 16:44:45 +0200 Subject: [PATCH 03/18] Move VS 2019 builds from AppVeyor to GH Actions GitHub runners unfortunately do not come with MinGW or VS 2010 pre-installed, so moving those builds will be more involved. MinGW-w64 is not a good replacement for MinGW as it is far more complete. This gives at least some feedback for all supported platforms via the GitHub Actions system. --- .appveyor.yml | 18 ++---------------- .github/workflows/build.yml | 31 ++++++++++++++++++++++++++++--- 2 files changed, 30 insertions(+), 19 deletions(-) diff --git a/.appveyor.yml b/.appveyor.yml index a21829a6..a4a01666 100644 --- a/.appveyor.yml +++ b/.appveyor.yml @@ -1,6 +1,5 @@ image: - Visual Studio 2015 - - Visual Studio 2019 branches: only: - ci @@ -21,26 +20,13 @@ environment: - GENERATOR: Visual Studio 10 2010 BUILD_SHARED_LIBS: OFF CFLAGS: /WX - - GENERATOR: Visual Studio 16 2019 - BUILD_SHARED_LIBS: ON - CFLAGS: /WX - - GENERATOR: Visual Studio 16 2019 - BUILD_SHARED_LIBS: OFF - CFLAGS: /WX matrix: fast_finish: true - exclude: - - image: Visual Studio 2015 - GENERATOR: Visual Studio 16 2019 - - image: Visual Studio 2019 - GENERATOR: Visual Studio 10 2010 - - image: Visual Studio 2019 - GENERATOR: MinGW Makefiles for: - matrix: - except: - - GENERATOR: Visual Studio 10 2010 + only: + - GENERATOR: MinGW Makefiles build_script: - set PATH=%PATH:C:\Program Files\Git\usr\bin=C:\MinGW\bin% - cmake -S . -B build -G "%GENERATOR%" -DBUILD_SHARED_LIBS=%BUILD_SHARED_LIBS% diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 74b28e4a..f3058c0d 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -6,14 +6,14 @@ on: permissions: statuses: write contents: read -env: - CC: clang - CFLAGS: -Werror jobs: build-linux-x11-clang: name: X11 (Linux, Clang) runs-on: ubuntu-latest + env: + CC: clang + CFLAGS: -Werror steps: - uses: actions/checkout@v2 - name: Install dependencies @@ -34,6 +34,9 @@ jobs: build-linux-wayland-clang: name: Wayland (Linux, Clang) runs-on: ubuntu-latest + env: + CC: clang + CFLAGS: -Werror steps: - uses: actions/checkout@v2 - name: Install dependencies @@ -54,6 +57,9 @@ jobs: build-linux-null-clang: name: Null (Linux, Clang) runs-on: ubuntu-latest + env: + CC: clang + CFLAGS: -Werror steps: - uses: actions/checkout@v2 - name: Install dependencies @@ -75,6 +81,7 @@ jobs: name: Cocoa (macOS, Clang) runs-on: macos-latest env: + CFLAGS: -Werror MACOSX_DEPLOYMENT_TARGET: 10.8 steps: - uses: actions/checkout@v2 @@ -89,3 +96,21 @@ jobs: - name: Build shared library run: cmake --build build-shared --parallel + build-windows-win32-vs2019: + name: Win32 (Windows, VS2019) + runs-on: windows-latest + env: + CFLAGS: /WX + steps: + - uses: actions/checkout@v2 + + - name: Configure static library + run: cmake -S . -B build-static -G "Visual Studio 16 2019" + - name: Build static library + run: cmake --build build-static --parallel + + - name: Configure shared library + run: cmake -S . -B build-shared -G "Visual Studio 16 2019" -D BUILD_SHARED_LIBS=ON + - name: Build shared library + run: cmake --build build-shared --parallel + From 3b132286502edbed1d05145e7e7e1a8cd7d8b976 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Camilla=20L=C3=B6wy?= Date: Wed, 9 Jun 2021 16:48:34 +0200 Subject: [PATCH 04/18] Add 'latest' branch to all CI builds With 3.4, the tip of the 'latest' branch will be a merge commit for 3.3-stable and the main branch, and not simply a fast-foward to an already tested commit. This sets up a tiny additional safety net before that merge. --- .appveyor.yml | 1 + .github/workflows/build.yml | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/.appveyor.yml b/.appveyor.yml index a4a01666..2742949b 100644 --- a/.appveyor.yml +++ b/.appveyor.yml @@ -4,6 +4,7 @@ branches: only: - ci - master + - latest - 3.3-stable skip_tags: true environment: diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index f3058c0d..d87ae8d1 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -2,7 +2,7 @@ name: Build on: pull_request: push: - branches: [ ci, master, 3.3-stable ] + branches: [ ci, master, latest, 3.3-stable ] permissions: statuses: write contents: read From 78380c7761043b0e4ab1190e3cccbe4d94359aa6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Camilla=20L=C3=B6wy?= Date: Wed, 9 Jun 2021 22:36:13 +0200 Subject: [PATCH 05/18] Update IRC network to Libera.Chat The `#glfw` IRC channel is moving to the Libera.Chat network due to the recent takeover of the Freenode network. --- README.md | 2 +- docs/CONTRIBUTING.md | 2 +- docs/SUPPORT.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 023d99fd..04a310ba 100644 --- a/README.md +++ b/README.md @@ -249,7 +249,7 @@ well as news, documentation and other information about the project. If you have questions related to the use of GLFW, we have a [forum](https://discourse.glfw.org/), and the `#glfw` IRC channel on -[Freenode](http://freenode.net/). +[Libera.Chat](https://libera.chat/). If you have a bug to report, a patch to submit or a feature you'd like to request, please file it in the diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 070cff95..11ddf09b 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -24,7 +24,7 @@ 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 -[Freenode](http://freenode.net/). +[Libera.Chat](https://libera.chat/). 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 diff --git a/docs/SUPPORT.md b/docs/SUPPORT.md index 604957d0..fdef2597 100644 --- a/docs/SUPPORT.md +++ b/docs/SUPPORT.md @@ -5,7 +5,7 @@ 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 -[Freenode](http://freenode.net/). +[Libera.Chat](https://libera.chat/). Bugs are reported to our [issue tracker](https://github.com/glfw/glfw/issues). Please check the [contribution From 787295b3aff950abd45bee3495ac1200eb6bc5e1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Camilla=20L=C3=B6wy?= Date: Wed, 9 Jun 2021 22:43:27 +0200 Subject: [PATCH 06/18] Fix some documentation URLs still using http: Some URLs in the documentation were overlooked during the switch to https: for the GLFW website. This updates those and a few third-party URLs. --- README.md | 24 ++++++++++++------------ docs/SUPPORT.md | 2 +- 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index 04a310ba..7fd862b4 100644 --- a/README.md +++ b/README.md @@ -14,18 +14,18 @@ GLFW natively supports Windows, macOS and Linux and other Unix-like systems. On Linux both X11 and Wayland are supported. GLFW is licensed under the [zlib/libpng -license](http://www.glfw.org/license.html). +license](https://www.glfw.org/license.html). -You can [download](http://www.glfw.org/download.html) the latest stable release +You can [download](https://www.glfw.org/download.html) the latest stable release as source or Windows binaries, or fetch the `latest` branch from GitHub. Each release starting with 3.0 also has a corresponding [annotated tag](https://github.com/glfw/glfw/releases) with source and binary archives. -The [documentation](http://www.glfw.org/docs/latest/) is available online and is +The [documentation](https://www.glfw.org/docs/latest/) is available online and is included in all source and binary archives. See the [release notes](https://www.glfw.org/docs/latest/news.html) for new features, caveats and deprecations in the latest release. For more details see the [version -history](http://www.glfw.org/changelog.html). +history](https://www.glfw.org/changelog.html). The `master` branch is the stable integration branch and _should_ always compile and run on all supported platforms, although details of newly added features may @@ -34,9 +34,9 @@ fixes live in [other branches](https://github.com/glfw/glfw/branches/all) until they are stable enough to merge. If you are new to GLFW, you may find the -[tutorial](http://www.glfw.org/docs/latest/quick.html) for GLFW 3 useful. If +[tutorial](https://www.glfw.org/docs/latest/quick.html) for GLFW 3 useful. If you have used GLFW 2 in the past, there is a [transition -guide](http://www.glfw.org/docs/latest/moving.html) for moving to the GLFW +guide](https://www.glfw.org/docs/latest/moving.html) for moving to the GLFW 3 API. @@ -52,16 +52,16 @@ MinGW-w64, on macOS with Clang and on Linux and other Unix-like systems with GCC and Clang. It will likely compile in other environments as well, but this is not regularly tested. -There are [pre-compiled Windows binaries](http://www.glfw.org/download.html) +There are [pre-compiled Windows binaries](https://www.glfw.org/download.html) available for all supported compilers. -See the [compilation guide](http://www.glfw.org/docs/latest/compile.html) for +See the [compilation guide](https://www.glfw.org/docs/latest/compile.html) for more information about how to compile GLFW yourself. ## Using GLFW -See the [documentation](http://www.glfw.org/docs/latest/) for tutorials, guides +See the [documentation](https://www.glfw.org/docs/latest/) for tutorials, guides and the API reference. @@ -79,7 +79,7 @@ Unix-like systems running the X Window System are supported even without a desktop environment or modern extensions, although some features require a running window or clipboard manager. The OSMesa backend requires Mesa 6.3. -See the [compatibility guide](http://www.glfw.org/docs/latest/compat.html) +See the [compatibility guide](https://www.glfw.org/docs/latest/compat.html) in the documentation for more information. @@ -102,7 +102,7 @@ located in the `deps/` directory. - [Nuklear](https://github.com/Immediate-Mode-UI/Nuklear) for test and example UI - [stb\_image\_write](https://github.com/nothings/stb) for writing images to disk -The documentation is generated with [Doxygen](http://doxygen.org/) if CMake can +The documentation is generated with [Doxygen](https://doxygen.org/) if CMake can find that tool. @@ -244,7 +244,7 @@ information on what to include when reporting a bug. ## Contact -On [glfw.org](http://www.glfw.org/) you can find the latest version of GLFW, as +On [glfw.org](https://www.glfw.org/) you can find the latest version of GLFW, as well as news, documentation and other information about the project. If you have questions related to the use of GLFW, we have a diff --git a/docs/SUPPORT.md b/docs/SUPPORT.md index fdef2597..79a45a8f 100644 --- a/docs/SUPPORT.md +++ b/docs/SUPPORT.md @@ -1,6 +1,6 @@ # Support resources -See the [latest documentation](http://www.glfw.org/docs/latest/) for tutorials, +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 From 15e05adf67203baf5c6c5349240208502c68b27c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Camilla=20L=C3=B6wy?= Date: Mon, 14 Jun 2021 21:21:17 +0200 Subject: [PATCH 07/18] Add notes on getting the HDC of a window on Win32 Related to #1913. --- include/GLFW/glfw3native.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/include/GLFW/glfw3native.h b/include/GLFW/glfw3native.h index 108be68b..06021ef9 100644 --- a/include/GLFW/glfw3native.h +++ b/include/GLFW/glfw3native.h @@ -161,6 +161,14 @@ GLFWAPI const char* glfwGetWin32Monitor(GLFWmonitor* monitor); * @return The `HWND` of the specified window, or `NULL` if an * [error](@ref error_handling) occurred. * + * @remark The `HDC` associated with the window can be queried with the + * [GetDC](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getdc) + * function. + * @code + * HDC dc = GetDC(glfwGetWin32Window(window)); + * @endcode + * This DC is private and does not need to be released. + * * @thread_safety This function may be called from any thread. Access is not * synchronized. * @@ -177,6 +185,14 @@ GLFWAPI HWND glfwGetWin32Window(GLFWwindow* window); * @return The `HGLRC` of the specified window, or `NULL` if an * [error](@ref error_handling) occurred. * + * @remark The `HDC` associated with the window can be queried with the + * [GetDC](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getdc) + * function. + * @code + * HDC dc = GetDC(glfwGetWin32Window(window)); + * @endcode + * This DC is private and does not need to be released. + * * @thread_safety This function may be called from any thread. Access is not * synchronized. * From 6f7c61c6b3bac75168838a803fa8ce303879817d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Camilla=20L=C3=B6wy?= Date: Tue, 15 Jun 2021 18:14:56 +0200 Subject: [PATCH 08/18] Add missing changelog entry Related to #1843. --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 7fd862b4..eb970ec7 100644 --- a/README.md +++ b/README.md @@ -240,6 +240,7 @@ information on what to include when reporting a bug. (#442) - [EGL] Added ANGLE backend selection via `EGL_ANGLE_platform_angle` extension (#1380) + - [EGL] Bugfix: The `GLFW_DOUBLEBUFFER` context attribute was ignored (#1843) ## Contact From 5b73fc8b80011e9853e97e1c1fa3b566d69bf469 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Camilla=20L=C3=B6wy?= Date: Tue, 22 Jun 2021 00:06:51 +0200 Subject: [PATCH 09/18] Wayland: Fix case of epollshim find module name This fixes a warning during the configuration step of CMake. --- CMake/modules/FindEpollShim.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CMake/modules/FindEpollShim.cmake b/CMake/modules/FindEpollShim.cmake index 2facb419..f34d0709 100644 --- a/CMake/modules/FindEpollShim.cmake +++ b/CMake/modules/FindEpollShim.cmake @@ -13,5 +13,5 @@ if (EPOLLSHIM_INCLUDE_DIRS AND EPOLLSHIM_LIBRARIES) endif (EPOLLSHIM_INCLUDE_DIRS AND EPOLLSHIM_LIBRARIES) include(FindPackageHandleStandardArgs) -find_package_handle_standard_args(EPOLLSHIM DEFAULT_MSG EPOLLSHIM_LIBRARIES EPOLLSHIM_INCLUDE_DIRS) +find_package_handle_standard_args(EpollShim DEFAULT_MSG EPOLLSHIM_LIBRARIES EPOLLSHIM_INCLUDE_DIRS) mark_as_advanced(EPOLLSHIM_INCLUDE_DIRS EPOLLSHIM_LIBRARIES) From a89fcd20d8d03fef795211939bc19b87cb59bb87 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Camilla=20L=C3=B6wy?= Date: Tue, 22 Jun 2021 00:25:42 +0200 Subject: [PATCH 10/18] Wayland: Fix missing constant on FreeBSD On FreeBSD O_CLOEXEC is only available when _POSIX_C_SOURCE >= 200809. O_CLOEXEC is in turn required by the epollshim header. Issue reported on IRC. --- src/wl_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/wl_init.c b/src/wl_init.c index 21a808aa..1ba497b7 100644 --- a/src/wl_init.c +++ b/src/wl_init.c @@ -26,7 +26,7 @@ // It is fine to use C99 in this file because it will not be built with VS //======================================================================== -#define _POSIX_C_SOURCE 199309L +#define _POSIX_C_SOURCE 200809L #include "internal.h" From 52d8347d34b51229cb6029a351ef19cfe60835ca Mon Sep 17 00:00:00 2001 From: "A. Tombs" Date: Wed, 23 Jun 2021 08:16:53 +0100 Subject: [PATCH 11/18] Consistent subsections in compile guide In the compile guide, the "Dependencies for Linux and OSMesa" section looks to be one level too high in the hierarchy. I've moved it to be in line with the similarly-named sub-sub-sections. Closes #1923. --- docs/compile.dox | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/compile.dox b/docs/compile.dox index 7c88281b..83778cb6 100644 --- a/docs/compile.dox +++ b/docs/compile.dox @@ -109,7 +109,7 @@ Once you have installed the necessary packages, move on to @ref compile_generate. -@subsection compile_deps_osmesa Dependencies for Linux and OSMesa +@subsubsection compile_deps_osmesa Dependencies for Linux and OSMesa To compile GLFW for OSMesa, you need to install the OSMesa library and header packages. For example, on Ubuntu and other distributions based on Debian From 6876cf8d7e0e70dc3e4d7b0224d08312c9f78099 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Camilla=20L=C3=B6wy?= Date: Fri, 25 Jun 2021 19:49:38 +0200 Subject: [PATCH 12/18] Remove errors for gamepad element mismatch Because there are controllers in the wild using the same hardware ID despite having different numbers of buttons and axes, an error message was triggered that was only expected for a corrupted mapping database. This removes the error for now, in preparation for better error handling for gamepad mappings overall. Fixes #1763. --- README.md | 2 ++ src/input.c | 12 ------------ 2 files changed, 2 insertions(+), 12 deletions(-) diff --git a/README.md b/README.md index eb970ec7..0be9d388 100644 --- a/README.md +++ b/README.md @@ -141,6 +141,8 @@ information on what to include when reporting a bug. - Bugfix: Some extension loader headers did not prevent default OpenGL header inclusion (#1695) - Bugfix: Buffers were swapped at creation on single-buffered windows (#1873) + - Bugfix: Gamepad mapping updates could spam `GLFW_INVALID_VALUE` due to + incompatible controllers sharing hardware ID (#1763) - [Win32] Added the `GLFW_WIN32_KEYBOARD_MENU` window hint for enabling access to the window menu - [Win32] Added a version info resource to the GLFW DLL diff --git a/src/input.c b/src/input.c index 9cc0c366..56f8c84d 100644 --- a/src/input.c +++ b/src/input.c @@ -101,25 +101,13 @@ static _GLFWmapping* findValidMapping(const _GLFWjoystick* js) for (i = 0; i <= GLFW_GAMEPAD_BUTTON_LAST; i++) { if (!isValidElementForJoystick(mapping->buttons + i, js)) - { - _glfwInputError(GLFW_INVALID_VALUE, - "Invalid button in gamepad mapping %s (%s)", - mapping->guid, - mapping->name); return NULL; - } } for (i = 0; i <= GLFW_GAMEPAD_AXIS_LAST; i++) { if (!isValidElementForJoystick(mapping->axes + i, js)) - { - _glfwInputError(GLFW_INVALID_VALUE, - "Invalid axis in gamepad mapping %s (%s)", - mapping->guid, - mapping->name); return NULL; - } } } From f010d8b77dda7fa62a16e6afaf7156222be468b5 Mon Sep 17 00:00:00 2001 From: "David V. McKay" Date: Wed, 7 Jul 2021 23:25:35 -0400 Subject: [PATCH 13/18] Clarify "as you would" for beginners. fixes #1088 --- docs/compile.dox | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/docs/compile.dox b/docs/compile.dox index 83778cb6..aec93b3b 100644 --- a/docs/compile.dox +++ b/docs/compile.dox @@ -177,7 +177,12 @@ development environment, move on to @ref 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 -these files, as you would with any other project. +these files, as you would with any other project: + +@code{.sh} +cd +make install +@endcode Once the GLFW library is compiled, you are ready to build your applications, linking it to the GLFW library. See @ref build_guide for more information. From 1a5e07fd4b0a5b6a70e99bbc52470962824d6979 Mon Sep 17 00:00:00 2001 From: "David V. McKay" Date: Wed, 7 Jul 2021 23:44:22 -0400 Subject: [PATCH 14/18] realizing "as you would" is platform dependent specified "for linux or unix" and added a bit about using Visual Studio on Windows. --- docs/compile.dox | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/compile.dox b/docs/compile.dox index aec93b3b..c0cdb460 100644 --- a/docs/compile.dox +++ b/docs/compile.dox @@ -179,10 +179,12 @@ 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 these files, as you would with any other project: +e.g. on linux or unix, @code{.sh} cd make install @endcode +or on Windows, open the .sln file in Visual Studio and build via the file menu. Once the GLFW library is compiled, you are ready to build your applications, linking it to the GLFW library. See @ref build_guide for more information. From b6f7ead3c50fd33efcd4b1dd2244d3a6f03aaddb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Camilla=20L=C3=B6wy?= Date: Wed, 14 Jul 2021 17:56:05 +0200 Subject: [PATCH 15/18] Add credit Related to #1931. --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 0be9d388..92a133be 100644 --- a/README.md +++ b/README.md @@ -369,6 +369,7 @@ skills. - Adam Marcus - Célestin Marot - Kyle McDonald + - David V. McKay - David Medlock - Bryce Mehring - Jonathan Mercier From 3b9597048259a198f8f27db7d5eb0eab7de0d3b3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Camilla=20L=C3=B6wy?= Date: Thu, 8 Jul 2021 21:56:00 +0200 Subject: [PATCH 16/18] Improve library compilation guide somewhat Related to #1931. --- docs/compile.dox | 330 +++++++++++++++++++++++++++-------------------- 1 file changed, 190 insertions(+), 140 deletions(-) diff --git a/docs/compile.dox b/docs/compile.dox index c0cdb460..7bc665fe 100644 --- a/docs/compile.dox +++ b/docs/compile.dox @@ -10,164 +10,156 @@ build applications that use GLFW, see @ref build_guide. @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 +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. + GLFW uses [CMake](https://cmake.org/) to generate project files or makefiles -for a particular development environment. If you are on a Unix-like system such -as Linux or FreeBSD or have a package system like Fink, MacPorts, Cygwin or -Homebrew, you can install its CMake package. If not, you can download -installers for Windows and macOS from the -[CMake website](https://cmake.org/). +for your chosen development environment. To compile GLFW, first generate these +files with CMake and then use them to compile the GLFW library. -@note CMake only generates project files or makefiles. It does not compile the -actual GLFW library. To compile GLFW, first generate these files for your -chosen development environment and then use them to compile the actual GLFW -library. +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 +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. -@subsection compile_deps Dependencies +@subsection compile_deps Installing dependencies -Once you have installed CMake, make sure that all other dependencies are -available. On some platforms, GLFW needs a few additional packages to be -installed. See the section for your chosen platform and development environment -below. +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_msvc Dependencies for Visual C++ on Windows +@subsubsection compile_deps_x11 Dependencies for X11 on Unix-like systems -The Windows SDK bundled with Visual C++ already contains all the necessary -headers, link libraries and tools except for CMake. Move on to @ref -compile_generate. +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. - -@subsubsection compile_deps_mingw Dependencies for MinGW or MinGW-w64 on Windows - -Both the MinGW and the MinGW-w64 packages already contain all the necessary -headers, link libraries and tools except for CMake. Move on to @ref -compile_generate. - - -@subsubsection compile_deps_mingw_cross Dependencies for MinGW or MinGW-w64 cross-compilation - -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 -for 32- and 64-bit version of MinGW-w64, while Debian GNU/Linux and derivatives -like Ubuntu have the `mingw-w64` package for both. - -GLFW has CMake toolchain files in the `CMake/` directory that set up -cross-compilation of Windows binaries. To use these files you add an option -when running `cmake` to generate the project files or makefiles: +On Debian and derivates like Ubuntu the `xorg-dev` meta-package pulls in the +development packages for all of X11. @code{.sh} -cmake -DCMAKE_TOOLCHAIN_FILE= . +sudo apt install xorg-dev @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 -directory. For example, both the Debian/Ubuntu and Cygwin MinGW-w64 packages -have `/usr/x86_64-w64-mingw32` for the 64-bit compilers, so the correct -invocation would be: +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. @code{.sh} -cmake -DCMAKE_TOOLCHAIN_FILE=CMake/x86_64-w64-mingw32.cmake . +pkg install xorgproto @endcode -For more details see the article -[CMake Cross Compiling](https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/CrossCompiling) on -the CMake wiki. +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. -Once you have this set up, move on to @ref compile_generate. +Once you have the required depdendencies, move on to @ref compile_generate. -@subsubsection compile_deps_xcode Dependencies for Xcode on macOS +@subsubsection compile_deps_wayland Dependencies for Wayland on Unix-like systems -Xcode comes with all necessary tools except for CMake. The required headers -and libraries are included in the core macOS frameworks. Xcode can be -downloaded from the Mac App Store or from the ADC Member Center. +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. -Once you have Xcode installed, move on to @ref compile_generate. +On Debian and derivates like Ubuntu you will need the `libwayland-dev`, +`libxkbcommon-dev` and `wayland-protocols` packages. +@code{.sh} +sudo apt install libwayland-dev libxkbcommon-dev wayland-protocols +@endcode -@subsubsection compile_deps_x11 Dependencies for Linux and X11 +On FreeBSD you will need the `wayland`, `libxkbcommon` and `wayland-protocols` +packages. -To compile GLFW for X11, you need to have the X11 packages installed, as well as -the basic development tools like GCC and make. For example, on Ubuntu and other -distributions based on Debian GNU/Linux, you need to install the `xorg-dev` -package, which pulls in all X.org header packages. +@code{.sh} +pkg install wayland libxkbcommon wayland-protocols +@endcode -Once you have installed the necessary packages, move on to @ref -compile_generate. - - -@subsubsection compile_deps_wayland Dependencies for Linux and Wayland - -To compile GLFW for Wayland, you need to have the Wayland packages installed, -as well as the basic development tools like GCC and make. For example, on -Ubuntu and other distributions based on Debian GNU/Linux, you need to install -the `libwayland-dev` package, which contains all Wayland headers and pulls in -wayland-scanner, as well as the `wayland-protocols` package. - -Once you have installed the necessary packages, move on to @ref -compile_generate. - - -@subsubsection compile_deps_osmesa Dependencies for Linux and OSMesa - -To compile GLFW for OSMesa, you need to install the OSMesa library and header -packages. For example, on Ubuntu and other distributions based on Debian -GNU/Linux, you need to install the `libosmesa6-dev` package. The OSMesa library -is required at runtime for context creation and is loaded on demand. - -Once you have installed the necessary packages, move on to @ref -compile_generate. +Once you have the required depdendencies, move on to @ref compile_generate. @subsection compile_generate Generating build files with CMake Once you have all necessary dependencies it is time to generate the project -files or makefiles for your development environment. CMake needs to know two -paths for this: the path to the _root_ directory of the GLFW source tree (i.e. -_not_ the `src` subdirectory) and the target path for the generated files and -compiled binaries. If these are the same, it is called an in-tree build, -otherwise it is called an out-of-tree build. +files or makefiles for your development environment. CMake needs two paths for +this: -One of several advantages of out-of-tree builds is that you can generate files -and compile for different development environments using a single source tree. + - the path to the root directory of the GLFW source tree (not its `src` + subdirectory) + - the path to the directory where the generated build files and compiled + binaries will be placed -@note This section is about generating the project files or makefiles necessary -to compile the GLFW library, not about compiling the actual library. +If these are the same, it is called an in-tree build, otherwise it is called an +out-of-tree build. + +Out-of-tree builds are recommended as they avoid cluttering up the source tree. +They also allow you to have several build directories for different +configurations all using the same source tree. + +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_cli Generating files with the CMake command-line tool +@subsubsection compile_generate_gui Generating files with the CMake GUI -To make an in-tree build, enter the _root_ directory of the GLFW source tree -(i.e. _not_ the `src` subdirectory) and run CMake. The current directory is -used as target path, while the path provided as an argument is used to find the -source tree. +Start the CMake GUI and set the paths to the source and build directories +described above. Then press _Configure_ and _Generate_. -@code{.sh} -cd -cmake . -@endcode +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. -To make an out-of-tree build, make a directory outside of the source tree, enter -it and run CMake with the (relative or absolute) path to the root of the source -tree as an argument. - -@code{.sh} -mkdir glfw-build -cd glfw-build -cmake -@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` 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_gui Generating files with the CMake GUI +@subsubsection compile_generate_cli Generating files with the CMake command-line tool -If you are using the GUI version, choose the root of the GLFW source tree as -source location and the same directory or another, empty directory as the -destination for binaries. Choose _Configure_, change any options you wish to, -_Configure_ again to let the changes take effect and then _Generate_. +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} +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} +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} +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. + +@code{.sh} +cmake -S path/to/glfw -B path/to/build -D GLFW_USE_WAYLAND=1 +@endcode Once you have generated the project files or makefiles for your chosen development environment, move on to @ref compile_compile. @@ -177,20 +169,39 @@ development environment, move on to @ref 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 -these files, as you would with any other project: +these files as you would with any other project. + +With Visual Studio open `GLFW.sln` and use the Build menu. With Xcode open +`GLFW.xcodeproj` and use the Project menu. + +With Linux, macOS and other forms of Unix, run `make`. -e.g. on linux or unix, @code{.sh} -cd -make install +cd path/to/build +make @endcode -or on Windows, open the .sln file in Visual Studio and build via the file menu. -Once the GLFW library is compiled, you are ready to build your applications, +With MinGW, it is `mingw32-make`. + +@code{.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} +cmake --build path/to/build +@endcode + +This will run the platform specific build tool the directory was generated for. + +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. -@subsection compile_options CMake options +@section compile_options CMake 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 @@ -206,59 +217,103 @@ 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} -cmake -DBUILD_SHARED_LIBS=ON . +cmake -S path/to/glfw -B path/to/build -D BUILD_SHARED_LIBS=ON @endcode -@subsubsection compile_options_shared Shared CMake options +@subsection compile_options_shared Shared CMake options @anchor BUILD_SHARED_LIBS __BUILD_SHARED_LIBS__ determines whether GLFW is built as a static -library or as a DLL / shared library / dynamic library. +library or as a DLL / shared library / dynamic library. This is disabled by +default, producing a static GLFW library. @anchor GLFW_BUILD_EXAMPLES __GLFW_BUILD_EXAMPLES__ determines whether the GLFW examples are built along with the library. This is enabled by default unless GLFW is being built -as a sub-project. +as a sub-project of a larger CMake project. @anchor GLFW_BUILD_TESTS __GLFW_BUILD_TESTS__ determines whether the GLFW test programs are built along with the library. This is enabled by default unless GLFW is being -built as a sub-project. +built as a sub-project of a larger CMake project. @anchor GLFW_BUILD_DOCS __GLFW_BUILD_DOCS__ determines whether the GLFW documentation is built along -with the library. +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. +directly with the application. This is disabled by default. -@subsubsection compile_options_win32 Windows specific CMake options +@subsection compile_options_win32 Windows specific CMake options @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. If set to `ON`, the -DLL version of the Visual C++ library is used. +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. -@note On CMake 3.15 and later you can set the +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) -variable instead of this option. +variable instead of this GLFW-specific option. @anchor GLFW_USE_HYBRID_HPG __GLFW_USE_HYBRID_HPG__ determines whether to export the `NvOptimusEnablement` and `AmdPowerXpressRequestHighPerformance` symbols, which force the use of the high-performance GPU on Nvidia Optimus and AMD PowerXpress systems. These symbols need to be exported by the EXE to be detected by the driver, so the override -will not work if GLFW is built as a DLL. +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 + +@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. + + +@section compile_mingw_cross Cross-compilation with CMake and MinGW + +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 +for 32- and 64-bit version of MinGW-w64, while Debian GNU/Linux and derivatives +like Ubuntu have the `mingw-w64` package for both. + +GLFW has CMake toolchain files in the `CMake` subdirectory that set up +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} +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 +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} +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). @section compile_manual Compiling GLFW manually 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's +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. @@ -290,11 +345,6 @@ of @b _GLFW_VULKAN_LIBRARY, @b _GLFW_EGL_LIBRARY, @b _GLFW_GLX_LIBRARY, @b _GLFW_OSMESA_LIBRARY, @b _GLFW_OPENGL_LIBRARY, @b _GLFW_GLESV1_LIBRARY and @b _GLFW_GLESV2_LIBRARY. Otherwise, GLFW will use the built-in default names. -For the EGL context creation API, the following options are available: - - - @b _GLFW_USE_EGLPLATFORM_H to use an existing `EGL/eglplatform.h` header file - for native handle types (fallback) - @note None of the @ref build_macros may be defined during the compilation of GLFW. If you define any of these in your build files, make sure they are not applied to the GLFW sources. From 836e709503f600436f582318a06efb8a8b33f2ad Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Camilla=20L=C3=B6wy?= Date: Mon, 5 Jul 2021 20:26:38 +0200 Subject: [PATCH 17/18] Cocoa: Remove calls to -update on nil These calls have no effect unless the context was created with NSGL. --- src/cocoa_window.m | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/cocoa_window.m b/src/cocoa_window.m index b618dccc..b41c030d 100644 --- a/src/cocoa_window.m +++ b/src/cocoa_window.m @@ -243,7 +243,7 @@ static const NSRange kEmptyRange = { NSNotFound, 0 }; - (void)windowDidResize:(NSNotification *)notification { - if (window->context.client != GLFW_NO_API) + if (window->context.source == GLFW_NATIVE_CONTEXT_API) [window->context.nsgl.object update]; if (_glfw.ns.disabledCursorWindow == window) @@ -278,7 +278,7 @@ static const NSRange kEmptyRange = { NSNotFound, 0 }; - (void)windowDidMove:(NSNotification *)notification { - if (window->context.client != GLFW_NO_API) + if (window->context.source == GLFW_NATIVE_CONTEXT_API) [window->context.nsgl.object update]; if (_glfw.ns.disabledCursorWindow == window) @@ -397,7 +397,7 @@ static const NSRange kEmptyRange = { NSNotFound, 0 }; - (void)updateLayer { - if (window->context.client != GLFW_NO_API) + if (window->context.source == GLFW_NATIVE_CONTEXT_API) [window->context.nsgl.object update]; _glfwInputWindowDamage(window); From 076bfd55be45e7ba5c887d4b32aa03d26881a1fb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Camilla=20L=C3=B6wy?= Date: Fri, 16 Jul 2021 20:04:56 +0200 Subject: [PATCH 18/18] Cocoa: Fix MoltenVK layer scale out of sync The contents scale of the hosted CAMetalLayer created for MoltenVK was updated only after the GLFW content scale and framebuffer size events were emitted, causing the layer to get out of sync with the monitor the window was on. --- README.md | 2 ++ src/cocoa_window.m | 25 ++++++++++++------------- 2 files changed, 14 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index 92a133be..ebafc583 100644 --- a/README.md +++ b/README.md @@ -196,6 +196,8 @@ information on what to include when reporting a bug. regained focus (#1648,#1802) - [Cocoa] Bugfix: Monitor name query could segfault on macOS 11 (#1809,#1833) - [Cocoa] Bugfix: The install name of the installed dylib was relative (#1504) + - [Cocoa] Bugfix: The MoltenVK layer contents scale was updated only after + related events were emitted - [X11] Bugfix: The CMake files did not check for the XInput headers (#1480) - [X11] Bugfix: Key names were not updated when the keyboard layout changed (#1462,#1528) diff --git a/src/cocoa_window.m b/src/cocoa_window.m index b41c030d..8fe992d5 100644 --- a/src/cocoa_window.m +++ b/src/cocoa_window.m @@ -520,6 +520,18 @@ static const NSRange kEmptyRange = { NSNotFound, 0 }; { const NSRect contentRect = [window->ns.view frame]; const NSRect fbRect = [window->ns.view convertRectToBacking:contentRect]; + const float xscale = fbRect.size.width / contentRect.size.width; + const float yscale = fbRect.size.height / contentRect.size.height; + + if (xscale != window->ns.xscale || yscale != window->ns.yscale) + { + if (window->ns.retina && window->ns.layer) + [window->ns.layer setContentsScale:[window->ns.object backingScaleFactor]]; + + window->ns.xscale = xscale; + window->ns.yscale = yscale; + _glfwInputWindowContentScale(window, xscale, yscale); + } if (fbRect.size.width != window->ns.fbWidth || fbRect.size.height != window->ns.fbHeight) @@ -528,19 +540,6 @@ static const NSRange kEmptyRange = { NSNotFound, 0 }; window->ns.fbHeight = fbRect.size.height; _glfwInputFramebufferSize(window, fbRect.size.width, fbRect.size.height); } - - const float xscale = fbRect.size.width / contentRect.size.width; - const float yscale = fbRect.size.height / contentRect.size.height; - - if (xscale != window->ns.xscale || yscale != window->ns.yscale) - { - window->ns.xscale = xscale; - window->ns.yscale = yscale; - _glfwInputWindowContentScale(window, xscale, yscale); - - if (window->ns.retina && window->ns.layer) - [window->ns.layer setContentsScale:[window->ns.object backingScaleFactor]]; - } } - (void)drawRect:(NSRect)rect