#glfw-window #events #glfw #vulkan

sys glfw-sys-passthrough

An Open Source, multi-platform library for creating windows with OpenGL contexts and receiving input and events

5 stable releases

6.0.9 Apr 26, 2025
6.0.0 Apr 19, 2025
4.0.4+3.3.5 Apr 4, 2025
4.0.3+3.3.5 Jan 2, 2023
4.0.1+3.3.5 Aug 26, 2022

#255 in Hardware support

Download history 49/week @ 2025-01-22 47/week @ 2025-01-29 65/week @ 2025-02-05 64/week @ 2025-02-12 56/week @ 2025-02-19 60/week @ 2025-02-26 81/week @ 2025-03-05 75/week @ 2025-03-12 52/week @ 2025-03-19 77/week @ 2025-03-26 165/week @ 2025-04-02 82/week @ 2025-04-09 192/week @ 2025-04-16 829/week @ 2025-04-23 342/week @ 2025-04-30 381/week @ 2025-05-07

1,759 downloads per month
Used in 3 crates (via glfw-passthrough)

Zlib license

1.5MB
34K SLoC

C 29K SLoC // 0.1% comments Objective-C 3K SLoC // 0.1% comments Rust 1.5K SLoC // 0.3% comments Shell 15 SLoC // 0.5% comments

Glfw + Rust

This repo contains glfw-sys crate that provides FFI bindings to glfw. You are not really supposed to use this crate directly, but rather use glfw crate instead.

Design

This library has two main purposes:

  1. provide FFI bindings to glfw: pre-generated (fast compile times) and build-time generation (slower).
  2. link to glfw library: system builds (using pkg-config), source builds (using cmake) and pre-built official glfw libs (only for windows and mac).

For normal applications, you only need to care about 2 features:

  1. src-build - if you want to build from source. adds around 10 seconds of build time.
  2. static-link - if you want to link statically. On linux, this requires src-build too, so prefer dynamic linking during development for faster compile times.

Features

Building And Linking

NOTE: For emscripten, none of these features apply. We just pass the necessary flags like -sUSE_GLFW=3 to linker and simply let emscripten take care of things.

  • static-link - statically link glfw. If disabled, we will dynamically link glfw.

We try to build glfw in this order:

  • src-build - If enabled, build glfw from source (sources are included with crate). Ensure cmake is installed and any other required dependencies.
  • prebuilt-libs (only for windows/macos. ignored on other platforms) - If enabled, we download and link pre-built glfw libs from https://github.com/glfw/glfw/releases/.

NOTE: We use curl + tar (unzip on macos) to download and extract pre-built libs. mac/win10+ will have these by default.

Finally, if neither src-build nor prebuilt-libs feature is enabled, we will try to use pkg-config to find and link to system glfw libs.

Platform Backends (non-mac and non-windows only)

  • x11 and wayland - enables support for x11/wayland. Enable both and you can choose which one to use during initialization. x11/wayland are ignored on windows/macos platforms.

Vulkan

  • vulkan enables some vulkan convenience functions (eg: glfwVulkanSupported).
  • Only enable this if you need vulkan support.

Native Handles

These features expose native "HWND"/"NSWindow"/"X11Connection" etc.. handles. Unless you are using wgpu-like libs that need raw-window-handles, these features can be ignored.

  • native-handles - enable APIs to get platform specific window handles or display connections or monitor ids. useful for raw-window-handle support.
  • native-gl - enable APIs for getting platform specific gl contexts (wgl, egl, glx, nsgl etc..). Most users should ignore this.
  • native-egl - enable egl API even for x11 builds, if you plan to use egl contexts with x11 windows. Most users should ignore this.

Miscellaneous

  • osmesa - I have no idea. Ignore this unless you know what you are doing.
  • bindgen - generate glfw FFI bindings at build time from headers. See Below

Pre-Generated bindings

We generate FFI bindings at src/sys/pregenerated.rs and include them with the crate to keep the compile times fast. These are used when bindgen feature is disabled.

This contains core bindings, but skips platform specific bindings (eg: window handles or other platform specific API). Because generating them requires platform headers (eg: windows.h) and we can't provide headers for all platforms at once.

So, platform specific bindings are manually maintained by hand in src/sys/manual.rs.

Bindgen

When bindgen feature is turned on, we generate bindings with bindgen during build time. This is a fallback, when pre-generated bindings have any mistakes in them (eg: wrong types or missing functions). But this may add significant compile-time overhead.

These features will influence the bindings generated.

  • native-handles, native-egl, native-gl - This generates bindings by including system headers for specific types (eg: HWND from windows.h) and may bloat compile times a lot (25+ seconds on windows) due to inclusion of huge platform-specific headers.
  • vulkan - includes vulkan header for vk related types (eg: vkInstance).

Release Check List

  • When updating glfw version, make sure to checkout the submodule and commit it.
  • When updating glfw version, don't forget to change the url link in build.rs to download the pre-built libs of the correct version.
  • When updating glfw version, don't forget to update the pkg-config atleast_version argument.
  • Check that the bindings generated are the same on all platforms by checking the CI logs for the gen_bindings.sh step.

Dependencies