A multi-platform library for OpenGL, OpenGL ES, Vulkan, window and input



Build status Build status Coverity Scan


GLFW is an 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.

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.

You can download 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 with source and binary archives.

The documentation is available online and is included in all source and binary archives. See the release notes for new features, caveats and deprecations in the latest release. For more details see the version history.

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 change until they have been included in a release. New features and many bug fixes live in other branches until they are stable enough to merge.

If you are new to GLFW, you may find the tutorial for GLFW 3 useful. If you have used GLFW 2 in the past, there is a transition guide for moving to the GLFW 3 API.

Compiling GLFW

GLFW itself requires only the headers and libraries for your OS and window system. It does not need the headers for any context creation API (WGL, GLX, EGL, NSGL, OSMesa) or rendering API (OpenGL, OpenGL ES, Vulkan) to enable support for them.

GLFW supports compilation on Windows with Visual C++ 2010 and later, MinGW and 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 available for all supported compilers.

See the compilation guide for more information about how to compile GLFW yourself.

Using GLFW

See the documentation for tutorials, guides and the API reference.

Contributing to GLFW

See the contribution guide for more information.

System requirements

GLFW supports Windows XP and later and macOS 10.8 and later. Linux and other 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 in the documentation for more information.


GLFW itself needs only CMake 3.1 or later and the headers and libraries for your OS and window system.

The examples and test programs depend on a number of tiny libraries. These are located in the deps/ directory.

The documentation is generated with Doxygen if CMake can find that tool.

Reporting bugs

Bugs are reported to our issue tracker. Please check the contribution guide for information on what to include when reporting a bug.


  • Added GLFW_MOUSE_PASSTHROUGH window hint for letting mouse input pass through the window (#1236,#1568)
  • Added GLFW_FEATURE_UNAVAILABLE error for platform limitations (#1692)
  • Added GLFW_FEATURE_UNIMPLEMENTED error for incomplete backends (#1692)
  • Added GLFW_ANGLE_PLATFORM_TYPE init hint and GLFW_ANGLE_PLATFORM_TYPE_* values to select ANGLE backend (#1380)
  • Made joystick subsystem initialize at first use (#1284,#1646)
  • Updated the minimum required CMake version to 3.1
  • Disabled tests and examples by default when built as a CMake subdirectory
  • Bugfix: The CMake config-file package used an absolute path and was not relocatable (#1470)
  • Bugfix: Video modes with a duplicate screen area were discarded (#1555,#1556)
  • Bugfix: Compiling with -Wextra-semi caused warnings (#1440)
  • Bugfix: Built-in mappings failed because some OEMs re-used VID/PID (#1583)
  • Bugfix: Some extension loader headers did not prevent default OpenGL header inclusion (#1695)
  • [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
  • [Win32] Disabled framebuffer transparency on Windows 7 when DWM windows are opaque (#1512)
  • [Win32] Bugfix: GLFW_INCLUDE_VULKAN plus VK_USE_PLATFORM_WIN32_KHR caused symbol redefinition (#1524)
  • [Win32] Bugfix: The cursor position event was emitted before its cursor enter event (#1490)
  • [Win32] Bugfix: The window hint GLFW_MAXIMIZED did not move or resize the window (#1499)
  • [Win32] Bugfix: Disabled cursor mode interfered with some non-client actions
  • [Win32] Bugfix: Super key was not released after Win+V hotkey (#1622)
  • [Win32] Bugfix: glfwGetKeyName could access out of bounds and return an invalid pointer
  • [Win32] Bugfix: Some synthetic key events were reported as GLFW_KEY_UNKNOWN (#1623)
  • [Win32] Bugfix: Non-BMP Unicode codepoint input was reported as UTF-16
  • [Win32] Bugfix: Monitor functions could return invalid values after configuration change (#1761)
  • [Win32] Bugfix: Initialization would segfault on Windows 8 (not 8.1) (#1775)
  • [Win32] Bugfix: Duplicate size events were not filtered (#1610)
  • [Win32] Bugfix: Full screen windows were incorrectly resized by DPI changes (#1582)
  • [Win32] Bugfix: GLFW_SCALE_TO_MONITOR had no effect on systems older than Windows 10 version 1703 (#1511)
  • [Cocoa] Added support for VK_EXT_metal_surface (#1619)
  • [Cocoa] Added locating the Vulkan loader at runtime in an application bundle
  • [Cocoa] Moved main menu creation to GLFW initialization time (#1649)
  • [Cocoa] Changed EGLNativeWindowType from NSView to CALayer (#1169)
  • [Cocoa] Changed F13 key to report Print Screen for cross-platform consistency (#1786)
  • [Cocoa] Removed dependency on the CoreVideo framework
  • [Cocoa] Bugfix: glfwSetWindowSize used a bottom-left anchor point (#1553)
  • [Cocoa] Bugfix: Window remained on screen after destruction until event poll (#1412)
  • [Cocoa] Bugfix: Event processing before window creation would assert (#1543)
  • [Cocoa] Bugfix: Undecorated windows could not be iconified on recent macOS
  • [Cocoa] Bugfix: Touching event queue from secondary thread before main thread would abort (#1649)
  • [Cocoa] Bugfix: Non-BMP Unicode codepoint input was reported as UTF-16 (#1635)
  • [Cocoa] Bugfix: Failing to retrieve the refresh rate of built-in displays could leak memory
  • [Cocoa] Bugfix: Objective-C files were compiled as C with CMake 3.19 (#1787)
  • [Cocoa] Bugfix: Duplicate video modes were not filtered out (#1830)
  • [Cocoa] Bugfix: Menubar was not clickable on macOS 10.15+ until it lost and 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)
  • [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)
  • [X11] Bugfix: Decorations could not be enabled after window creation (#1566)
  • [X11] Bugfix: Content scale fallback value could be inconsistent (#1578)
  • [X11] Bugfix: glfwMaximizeWindow had no effect on hidden windows
  • [X11] Bugfix: Clearing GLFW_FLOATING on a hidden window caused invalid read
  • [X11] Bugfix: Changing GLFW_FLOATING on a hidden window could silently fail
  • [X11] Bugfix: Disabled cursor mode was interrupted by indicator windows
  • [X11] Bugfix: Monitor physical dimensions could be reported as zero mm
  • [X11] Bugfix: Window position events were not emitted during resizing (#1613)
  • [X11] Bugfix: glfwFocusWindow could terminate on older WMs or without a WM
  • [X11] Bugfix: Querying a disconnected monitor could segfault (#1602)
  • [X11] Bugfix: IME input of CJK was broken for "C" locale (#1587,#1636)
  • [X11] Bugfix: Termination would segfault if the IM had been destroyed
  • [X11] Bugfix: Any IM started after initialization would not be detected
  • [X11] Bugfix: Xlib errors caused by other parts of the application could be reported as GLFW errors
  • [X11] Bugfix: A handle race condition could cause a BadWindow error (#1633)
  • [X11] Bugfix: XKB path used keysyms instead of physical locations for non-printable keys (#1598)
  • [X11] Bugfix: Function keys were mapped to GLFW_KEY_UNKNOWN for some layout combinaitons (#1598)
  • [X11] Bugfix: Keys pressed simultaneously with others were not always reported (#1112,#1415,#1472,#1616)
  • [Wayland] Removed support for wl_shell (#1443)
  • [Wayland] Bugfix: The GLFW_HAND_CURSOR shape used the wrong image (#1432)
  • [Wayland] Bugfix: CLOCK_MONOTONIC was not correctly enabled
  • [Wayland] Bugfix: Repeated keys could be reported with NULL window (#1704)
  • [Wayland] Bugfix: Retrieving partial framebuffer size would segfault
  • [Wayland] Bugfix: Scrolling offsets were inverted compared to other platforms (#1463)
  • [Wayland] Bugfix: Client-Side Decorations were destroyed in the wrong worder (#1798)
  • [Wayland] Bugfix: Monitors physical size could report zero (#1784,#1792)
  • [POSIX] Bugfix: CLOCK_MONOTONIC was not correctly tested for or enabled
  • [NSGL] Removed enforcement of forward-compatible flag for core contexts
  • [NSGL] Bugfix: GLFW_COCOA_RETINA_FRAMEBUFFER had no effect on newer macOS versions (#1442)
  • [NSGL] Bugfix: Workaround for swap interval on 10.14 broke on 10.12 (#1483)
  • [EGL] Added platform selection via the EGL_EXT_platform_base extension (#442)
  • [EGL] Added ANGLE backend selection via EGL_ANGLE_platform_angle extension (#1380)


On 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 forum, and the #glfw IRC channel on Freenode.

If you have a bug to report, a patch to submit or a feature you'd like to request, please file it in the issue tracker on GitHub.

Finally, if you're interested in helping out with the development of GLFW or porting it to your favorite platform, join us on the forum, GitHub or IRC.


GLFW exists because people around the world donated their time and lent their skills.

  • Bobyshev Alexander
  • Laurent Aphecetche
  • Matt Arsenault
  • ashishgamedev
  • David Avedissian
  • Keith Bauer
  • John Bartholomew
  • Coşku Baş
  • Niklas Behrens
  • Andrew Belt
  • Nevyn Bengtsson
  • Niklas Bergström
  • Denis Bernard
  • Doug Binks
  • blanco
  • Kyle Brenneman
  • Rok Breulj
  • Kai Burjack
  • Martin Capitanio
  • Nicolas Caramelli
  • David Carlier
  • Arturo Castro
  • Chi-kwan Chan
  • Ian Clarkson
  • Michał Cichoń
  • Lambert Clara
  • Anna Clarke
  • Yaron Cohen-Tal
  • Omar Cornut
  • Andrew Corrigan
  • Bailey Cosier
  • Noel Cower
  • Jason Daly
  • Jarrod Davis
  • Olivier Delannoy
  • Paul R. Deppe
  • Michael Dickens
  • Роман Донченко
  • Mario Dorn
  • Wolfgang Draxinger
  • Jonathan Dummer
  • Ralph Eastwood
  • Fredrik Ehnbom
  • Robin Eklind
  • Siavash Eliasi
  • Felipe Ferreira
  • Michael Fogleman
  • Gerald Franz
  • Mário Freitas
  • GeO4d
  • Marcus Geelnard
  • Charles Giessen
  • Ryan C. Gordon
  • Stephen Gowen
  • Kovid Goyal
  • Eloi Marín Gratacós
  • Stefan Gustavson
  • Jonathan Hale
  • hdf89shfdfs
  • Sylvain Hellegouarch
  • Matthew Henry
  • heromyth
  • Lucas Hinderberger
  • Paul Holden
  • Warren Hu
  • Charles Huber
  • IntellectualKitty
  • Aaron Jacobs
  • Erik S. V. Jansson
  • Toni Jovanoski
  • Arseny Kapoulkine
  • Cem Karan
  • Osman Keskin
  • Josh Kilmer
  • Byunghoon Kim
  • Cameron King
  • Peter Knut
  • Christoph Kubisch
  • Yuri Kunde Schlesner
  • Rokas Kupstys
  • Konstantin Käfer
  • Eric Larson
  • Francis Lecavalier
  • Jong Won Lee
  • Robin Leffmann
  • Glenn Lewis
  • Shane Liesegang
  • Anders Lindqvist
  • Leon Linhart
  • Marco Lizza
  • Eyal Lotem
  • Aaron Loucks
  • Luflosi
  • lukect
  • Tristam MacDonald
  • Hans Mackowiak
  • Дмитри Малышев
  • Zbigniew Mandziejewicz
  • Adam Marcus
  • Célestin Marot
  • Kyle McDonald
  • David Medlock
  • Bryce Mehring
  • Jonathan Mercier
  • Marcel Metz
  • Liam Middlebrook
  • Ave Milia
  • Jonathan Miller
  • Kenneth Miller
  • Bruce Mitchener
  • Jack Moffitt
  • Jeff Molofee
  • Alexander Monakov
  • Pierre Morel
  • Jon Morton
  • Pierre Moulon
  • Martins Mozeiko
  • Julian Møller
  • ndogxj
  • Kristian Nielsen
  • Kamil Nowakowski
  • onox
  • Denis Ovod
  • Ozzy
  • Andri Pálsson
  • Peoro
  • Braden Pellett
  • Christopher Pelloux
  • Arturo J. Pérez
  • Vladimir Perminov
  • Anthony Pesch
  • Orson Peters
  • Emmanuel Gil Peyrot
  • Cyril Pichard
  • Keith Pitt
  • Stanislav Podgorskiy
  • Konstantin Podsvirov
  • Nathan Poirier
  • Alexandre Pretyman
  • Pablo Prietz
  • przemekmirek
  • pthom
  • Guillaume Racicot
  • Philip Rideout
  • Eddie Ringle
  • Max Risuhin
  • Jorge Rodriguez
  • Luca Rood
  • Ed Ropple
  • Aleksey Rybalkin
  • Mikko Rytkönen
  • Riku Salminen
  • Brandon Schaefer
  • Sebastian Schuberth
  • Christian Sdunek
  • Matt Sealey
  • Steve Sexton
  • Arkady Shapkin
  • Ali Sherief
  • Yoshiki Shibukawa
  • Dmitri Shuralyov
  • Daniel Skorupski
  • Bradley Smith
  • Cliff Smolinsky
  • Patrick Snape
  • Erlend Sogge Heggen
  • Julian Squires
  • Johannes Stein
  • Pontus Stenetorp
  • Michael Stocker
  • Justin Stoecker
  • Elviss Strazdins
  • Paul Sultana
  • Nathan Sweet
  • TTK-Bandit
  • Jared Tiala
  • Sergey Tikhomirov
  • Arthur Tombs
  • Ioannis Tsakpinis
  • Samuli Tuomola
  • Matthew Turner
  • urraka
  • Elias Vanderstuyft
  • Stef Velzel
  • Jari Vetoniemi
  • Ricardo Vieira
  • Nicholas Vitovitch
  • Simon Voordouw
  • Corentin Wallez
  • Torsten Walluhn
  • Patrick Walton
  • Xo Wang
  • Waris
  • Jay Weisskopf
  • Frank Wille
  • Andy Williams
  • Joel Winarske
  • Richard A. Wilkes
  • Tatsuya Yatagawa
  • Ryogo Yoshimura
  • Lukas Zanner
  • Andrey Zholos
  • Aihui Zhu
  • Santi Zupancic
  • Jonas Ådahl
  • Lasse Öörni
  • Leonard König
  • All the unmentioned and anonymous contributors in the GLFW community, for bug reports, patches, feedback, testing and encouragement
  • Option for transparent windows

    Option for transparent windows

    On X11, when using a compositor/compositing WM, windows can have alpha-enabled visuals, allowing the application to specify opacity of each pixel. This is not however supported by GLFW now.

    Here's some example code from Nvidia (note this works on Mesa as well): ftp://download.nvidia.com/XFree86/Linux-x86/177.70/README/chapter-23.html

    I hacked together a version of glxgears with transparent background, for reference: https://gist.github.com/nezumisama/8161902

    enhancement macOS Windows X11 Wayland Mir 
    opened by nezumisama 119
  • glfwPostEmptyEvent sometimes fails to unblock glfwWaitEvents on Ubuntu 18.04

    glfwPostEmptyEvent sometimes fails to unblock glfwWaitEvents on Ubuntu 18.04

    From times to times, the empty event posted by a call to glfwPostEmptyEvent won't unblock a call to glfwWaitEvent in the main thread.

    A minimal program reproducing the issue is available here It can be built and run on linux like so: g++ main.cpp -std=c++14 -lglfw -lX11 -ldl -lpthread && ./a.out

    If the calls of glfwPostEmptyEvent and glfwWaitEvent don't overlap in time, then the bug will never happen, but if the 2 calls are concurrent, the bug happens, "sometimes".

    Note that on OSX, this bug never happens.

    GLFW Version (from glfwGetVersionString()): 3.2.1 X11 GLX EGL clock_gettime /dev/js Xf86vm shared

    Ubuntu version 18.04 LTS

    • Note that I have tried posting "several" empty events at the same time: it doesn't help either, it just makes the bug a little less reproducible but doesnt fix it entirely.

    Edit : added the build command Edit2 : fixed the build command

    bug X11 verified 
    opened by OlivierSohn 63
  • Support for MoltenVK

    Support for MoltenVK

    We at Brenwill, developers of MoltenVK, have received user interest in GLFW supporting Vulkan on macOS (and iOS) by linking to MoltenVK.

    If there is GLFW community interest in this, we'd be happy to provide whatever support and advice we can to anyone in the GLFW development community who wishes to update GLFW to support Vulkan on macOS via MoltenVK.


    enhancement macOS Vulkan 
    opened by billhollings 47
  • _NET_REQUEST_FRAME_EXTENTS fails almost everywhere

    _NET_REQUEST_FRAME_EXTENTS fails almost everywhere

    with latest master, when calling glfwCreateWindow the call blocks forever on:

    #0  0x00007ffff47a6380 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81
    #1  0x00007fffefc1ab72 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
    #2  0x00007fffefc1c64f in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
    #3  0x00007ffff5fd33a8 in _XReadEvents () from /usr/lib/x86_64-linux-gnu/libX11.so.6
    #4  0x00007ffff5fbb889 in XIfEvent () from /usr/lib/x86_64-linux-gnu/libX11.so.6
    #5  0x00000000005ec1dc in createWindow ()
    #6  0x00000000005edcd0 in _glfwPlatformCreateWindow ()
    #7  0x00000000005e6570 in glfwCreateWindow ()

    this works fine with 3.0.4

    bug X11 external 
    opened by arturoc 44
  • make use of gamepad and joystick optional

    make use of gamepad and joystick optional

    Hi @elmindreda , is there a chance to have some way to "disable" the code for the joystick and gamepad if I don't have applications that make use of them? I made some investigations and I am sure that it will be an improvement at least at the startup of the app.

    We can define some cmake option for the gamepad and joystick which is enable by default and just disabled when you know for sure that you will use just mouse and keyboard. This option can set some macro and the code will not be compiled.

    I can write the code, if you are open to do such a scenario.

    enhancement macOS Windows Linux input 
    opened by ghost 38
  • Query for key text

    Query for key text

    1. Choose Dvorak keyboard layout
    2. Press Ctrl+S in a GLFW window
    3. Notice that the key comes in via glfwSetKeyCallback as Ctrl+(semicolon)
    4. Note that you get no charmods event (glfwSetCharModsCallback) so you cannot work around by handling the event via text input
    [email protected]:~$ lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description:    Ubuntu 14.10
    Release:    14.10
    Codename:   utopic
    enhancement macOS Windows X11 
    opened by andrewrk 33
  • Fix installation path of CMake package files

    Fix installation path of CMake package files

    Installation path prevented cmake from finding GLFW. It seems that INSTALL_DIRECTORY was correct but path provided to INSTALL command was not updated. Added GLFW_LIBRARIES export to glfwConfig.cmake.in as well.

    Now it is possible to use glfw with externalproject_add and find_package as follows:

    find_package(glfw3 REQUIRED)
    add_executable(foo foo.cpp)
    target_link_libraries(foo ${GLFW3_LIBRARY})
    bug enhancement build 
    opened by shaxbee 33
  • Additional Cursors

    Additional Cursors

    Please can you add definitions and support for the default cursors:

    resize diagonal top left resize diagonal bottom right resize diagonal top right resize diagonal bottom left alt select unavailable hand grab help select hand grab handwriting

    enhancement macOS Windows X11 Wayland 
    opened by imaginationcoin 33
  • Certain applications crash on wlroots compositors with: XDG surface must not have a buffer at creation

    Certain applications crash on wlroots compositors with: XDG surface must not have a buffer at creation


    When trying to run kitty as a native Wayland application, I ran into the following error: https://github.com/kovidgoyal/kitty/issues/157#issuecomment-389390996 , namely

    [email protected]: error 3: xdg_surface must not have a buffer at creation
    [135 23:29:00.699834] [glfw error 65544]: Wayland: Focusing a window requires user interaction
    [135 23:29:00.699870] [glfw error 65544]: Wayland: Window position retrieval not supported

    It seems that kitty and perhaps other apps using glfw for rendering allow the creation of a surface which already has a buffer attached, which is not allowed. For example, the sway window manager throws an error when launching kitty (https://github.com/swaywm/sway/issues/1992). Although kitty uses a patched version of glfw, the changes only pertain to some keyboard handling and I don't believe that is the source of the issue. I would appreciate any help - this is far from my area of expertise, so let me know if there is any other information I can provide that would be useful.

    Thank you!

    bug verified Wayland 
    opened by aenda 29
  • 3.3 release coordination

    3.3 release coordination

    Here is a place for figuring out what we need to do for the 3.3 release. As long as 3.3 hasn't been released there is still time to comment.

    Things that will go into 3.3

    These are what I (elmindreda) will focus on getting merged before starting on any of the other ones.

    • [x] Content scale queries (glfwGet*ContentScale) #235, #439 (implicitly), #676, #677, #845, #898
    • [x] Joystick axis fixes (XInput y-axis, ~IOHID x-axis~) #1083
      • very little work
    • [x] Full window opacity (GLFW_OPACITY) #1089
      • little work
    • [x] Lock key query (glfwGetKeyLock) #946
      • little work, all platforms
    • [x] Gamepad mapping modifiers
      • little work

    Things that could go into 3.3

    Most of these are relatively isolated and can be done without much coordination, the one major exception being joystick state callbacks. If you want to take on one of them then please leave a comment below so we can avoid duplicate work. Also, in many cases there is already a work-in-progress branch, some of them already on GitHub. I'll start pushing the remaining ones as soon as I'm able.

    If you are waiting for one of these features but would prefer that 3.3 not be delayed for it, please leave a comment. Also, if you have no personal interest in a feature but think it's worth delaying the release for it, please leave a comment and (optionally) explain why.

    • ~[ ] Joystick state callbacks (glfwSetJoystick*Callback) #601 (half of), #856~
      • some work, all platforms, intersects with event time
    • ~[ ] Joystick state query (glfwGetJoystickState, GLFWjoystickstate) #601 (half of)~
      • little work, shared code only
    • ~Event time (glfwGetEventTime) #1012~
    • ~EGLDevice backend (no API change) #786~
    • ~[ ] Disable screensaver via libdbus (no API change) #854~
      • some work, Unix only
    • ~Native handle attachment (function name needed) #25~
    • ~IME functions (pre-edit event, pre-edit window position, IME toggle) #41, #658~
    • [x] macOS window occlusion (design needed) #680
      • unknown amount of work

    There are also many very valuable ways to contribute other than making feature PRs.

    I know some of you are very familiar with the internals and conventions of GLFW. You could team up with and mentor someone new to the project who is taking on one of the above features and get the PR from promising to ready to merge.

    Documentation bug reports and PRs are always welcome. There has been a lot of documentation added or changed since the last release. There will be mistakes in it, as well as awkward phrasings and poor explanations. The compilation and build guides are especially terrible and could use both improvements, expansion and (especially for the GUI parts) lots of images (default system DPI, default UI theme).

    ~The Doxygen custom CSS needs to be updated since Doxygen broke tons of the current one in a recent release. Most importantly the colors of the new dynamic menus. This one doesn't have an issue so open one if you're taking this on.~ Done by @siavashserver in #1100

    Is your project using GLFW? Are you still using 3.2.1 or earlier? Try running it on 3.3 and see if everything works. If not, please open an issue ASAP.

    Do you have any joysticks or controllers laying around? There have been major changes to the macOS joystick backend, the Linux one has been replaced entirely and the SDL_gamecontrollerdb support needs all the testing it can get.

    Since we just added a new parser with glfwUpdateGamepadMappings, run fuzzers against it and report or fix any bugs they find.

    Meta-contributions: suggest new suggestions for this list.

    meta help needed 
    opened by elmindreda 29
  • Letterboxed rendering for full screen windows on Retina MBP

    Letterboxed rendering for full screen windows on Retina MBP

    Mac OS: 10.8.4 Mac: Macbook Pro w/ Retina 15" (MC950LL) (2880x1800) ran at 1440*900 RAM: 16GB Video Card: Switchable Intel HD 4000 / nVidia 650 GT

    Commit: "7423cfa5bf3324c0526a92d9d7a5aa36bf0c7604"

    Whenever I choose to put GLFW into Full Screen on my Retina using glfwGetPrimaryMonitor() it is not matching my appropriate resolution, at least it appears that way.

    What happens is everything inside of the OpenGL View is fuzzy, it almost looks like when it went full screen that it didn't go to my computers resolution. I can assure you that this is not due to the fact that I'm seeing it pixely because I'm on a retina... Its actually fuzzy, like the aspect ratio is off. Also on the top and bottom of my screen there is a black bar. Both black bars are about 100 Pixels in height and the width of the black bar is the width of my monitor. I set the glColor to blue so thats how I see the black bar. Its also not an issue with GLFWvidmode because its reporting the proper resolution for my display.


    GLFWvidmode mainMonVidMode = glfwGetVideoMode(glfwGetPrimaryMonitor()); GLFWwindow* window = glfwCreateWindow(mainMonVidMode.width, mainMonVidMode.height, "Welcome to My Game", glfwGetPrimaryMonitor(), NULL); if (!window) { glfwTerminate(); exit(EXIT_FAILURE); } glfwMakeContextCurrent(window);

    I also cannot figure out why this is happening in the source code of GLFW 3.0 either. In cocoa_window.m the following code is the proper code to enter full screen. However once it goes into full screen like I said everything is blurry like it didn't go into fullscreen at the proper resolution.

    if (wndconfig->monitor) { if (!_glfwSetVideoMode(window->monitor, &window->videoMode)) return GL_FALSE; _glfwPlatformShowWindow(window); [[window->ns.object contentView] enterFullScreenMode:wndconfig->monitor->ns.screen withOptions:nil]; }

    bug macOS High DPI 
    opened by jaredjones 29
  • Has a DLL hijacking problem on Windows.

    Has a DLL hijacking problem on Windows.

    When I use glfw to create a window in Windows, I find that the system dynamic library loaded through loadlibraryA in win32_init does not display the specified path. As a result, DLL hijacking occurs.

    opened by seaside-wu 0
  • POSIX Time Issue on older glibc

    POSIX Time Issue on older glibc

    OS and version: CentOS 6.6 Compiler version: GCC v4.8.5 Release or commit: lastest master as of writing (da6713cd096a40a4512f468b34c189017e73f987) Build log:

    [[email protected] build]# make
    Scanning dependencies of target glfw
    [  1%] Building C object src/CMakeFiles/glfw.dir/posix_time.c.o
    /root/test/glfw-master/src/posix_time.c: In function ‘_glfwPlatformInitTimer’:
    /root/test/glfw-master/src/posix_time.c:42:31: error: ‘CLOCK_REALTIME’ undeclared (first use in this function)
         _glfw.timer.posix.clock = CLOCK_REALTIME;
    /root/test/glfw-master/src/posix_time.c:42:31: note: each undeclared identifier is reported only once for each function it appears in
    /root/test/glfw-master/src/posix_time.c:47:5: warning: implicit declaration of function ‘clock_gettime’ [-Wimplicit-function-declaration]
         if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0)
    /root/test/glfw-master/src/posix_time.c:47:23: error: ‘CLOCK_MONOTONIC’ undeclared (first use in this function)
         if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0)
    make[2]: *** [src/CMakeFiles/glfw.dir/posix_time.c.o] Error 1
    make[1]: *** [src/CMakeFiles/glfw.dir/all] Error 2
    make: *** [all] Error 2

    The issue: CLOCK_REALTIME and CLOCK_MONOTONIC might not be defined, however they may still be available if used in a non-standard way. This mostly affects older Linux distros.

    Adding these three lines to the beginning of src/posix_time.c would fix the issue:


    I've added them myself and the library compiles fine.

    Potential issues: None that I can see anyway.

    bug Linux build 
    opened by eezstreet 0
  • macOS shared context issue

    macOS shared context issue


    There seems to be a problem when having more than 4 shared contexts, the render becomes very slow.

    I've posted a modifed "windows" sample below to showcase the issue.

    If NUM_WINDOWS is 4, you should see in logs

    render took 0.366000 milliseconds

    But if NUM_WINDOWS is 5 or more, you will see this:

    render took 2.987000 milliseconds.

    This is much more noticeable when rendering multiple complex scenes in multiple windows at once (the increase in time has the same factor, from 2-3 ms to 22 ms). There is no increase from 1 context to 2,3, or 4. But as soon as you add a 5'th (or more) shared context rendering takes 10 times more.

    Any ideas what could cause this?

    #include <glad/gl.h>
    #include <GLFW/glfw3.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include <sys/time.h>
    #include <stdio.h>
    #include "linmath.h"
    #define NUM_WINDOWS 4
    float timedifference_msec(struct timeval t0, struct timeval t1)
        return (t1.tv_sec - t0.tv_sec) * 1000.0f + (t1.tv_usec - t0.tv_usec) / 1000.0f;
    typedef struct Vertex
        vec2 pos;
        vec3 col;
    } Vertex;
    static const Vertex vertices[3] =
        { { -0.6f, -0.4f }, { 1.f, 0.f, 0.f } },
        { {  0.6f, -0.4f }, { 0.f, 1.f, 0.f } },
        { {   0.f,  0.6f }, { 0.f, 0.f, 1.f } }
    static const char* vertex_shader_text =
    "#version 330\n"
    "uniform mat4 MVP;\n"
    "in vec3 vCol;\n"
    "in vec2 vPos;\n"
    "out vec3 color;\n"
    "void main()\n"
    "    gl_Position = MVP * vec4(vPos, 0.0, 1.0);\n"
    "    color = vCol;\n"
    static const char* fragment_shader_text =
    "#version 330\n"
    "in vec3 color;\n"
    "out vec4 fragment;\n"
    "void main()\n"
    "    fragment = vec4(color, 1.0);\n"
    int main(int argc, char** argv)
        int xpos, ypos, height;
        const char* description;
        GLFWwindow* windows[NUM_WINDOWS];
        if (!glfwInit())
            printf("Error: %s\n", description);
        glfwWindowHint(GLFW_VISIBLE, GLFW_FALSE);
        //glfwWindowHint(GLFW_DECORATED, GLFW_FALSE);
        glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
        glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
        glfwGetMonitorWorkarea(glfwGetPrimaryMonitor(), &xpos, &ypos, NULL, &height);
        for (int i = 0;  i < NUM_WINDOWS;  i++)
            const int size = height / NUM_WINDOWS;
            const struct
                float r, g, b;
            } colors[] =
                { 0.95f, 0.32f, 0.11f },
                { 0.50f, 0.80f, 0.16f },
                {   0.f, 0.68f, 0.94f },
                { 0.98f, 0.74f, 0.04f },
                {   0.f, 0.f, 0.f }
            if (i > 0)
                glfwWindowHint(GLFW_FOCUS_ON_SHOW, GLFW_FALSE);
            windows[i] = glfwCreateWindow(size, size, "Multi-Window Example", NULL, i == 0 ? NULL : windows[0]);
            if (!windows[i])
                printf("Error: %s\n", description);
                             xpos + size * (1 + (i & 1)),
                             ypos + size * (1 + (i >> 1)));
            glfwSetInputMode(windows[i], GLFW_STICKY_KEYS, GLFW_TRUE);
            glClearColor(colors[0].r, colors[0].g, colors[0].b, 1.f);
        for (int i = 0;  i < NUM_WINDOWS;  i++)
        GLuint vertex_buffer;
        glGenBuffers(1, &vertex_buffer);
        glBindBuffer(GL_ARRAY_BUFFER, vertex_buffer);
        glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);
        const GLuint vertex_shader = glCreateShader(GL_VERTEX_SHADER);
        glShaderSource(vertex_shader, 1, &vertex_shader_text, NULL);
        const GLuint fragment_shader = glCreateShader(GL_FRAGMENT_SHADER);
        glShaderSource(fragment_shader, 1, &fragment_shader_text, NULL);
        const GLuint program = glCreateProgram();
        glAttachShader(program, vertex_shader);
        glAttachShader(program, fragment_shader);
        const GLint mvp_location = glGetUniformLocation(program, "MVP");
        const GLint vpos_location = glGetAttribLocation(program, "vPos");
        const GLint vcol_location = glGetAttribLocation(program, "vCol");
        GLuint vertex_array;
        glGenVertexArrays(1, &vertex_array);
        glVertexAttribPointer(vpos_location, 2, GL_FLOAT, GL_FALSE,
                              sizeof(Vertex), (void*) offsetof(Vertex, pos));
        glVertexAttribPointer(vcol_location, 3, GL_FLOAT, GL_FALSE,
                              sizeof(Vertex), (void*) offsetof(Vertex, col));
        for (;;)
            for (int i = 0;  i < NUM_WINDOWS;  i++)
                struct timeval t0;
                struct timeval t1;
                float elapsed;
                gettimeofday(&t0, 0);
                int width, height;
                glfwGetFramebufferSize(windows[i], &width, &height);
                const float ratio = width / (float) height;
                glViewport(0, 0, width, height);
                mat4x4 m, p, mvp;
                mat4x4_rotate_Z(m, m, (float) glfwGetTime());
                mat4x4_ortho(p, -ratio, ratio, -1.f, 1.f, 1.f, -1.f);
                mat4x4_mul(mvp, p, m);
                glUniformMatrix4fv(mvp_location, 1, GL_FALSE, (const GLfloat*) &mvp);
                glDrawArrays(GL_TRIANGLES, 0, 3);
                gettimeofday(&t1, 0);
                elapsed = timedifference_msec(t0, t1);
                printf("render took %f milliseconds.\n", elapsed);
    macOS OpenGL 
    opened by adrianmdumitru 1
  • glfwGetWindowMonitor returns wrong monitor after changing the window of monitor

    glfwGetWindowMonitor returns wrong monitor after changing the window of monitor


    OS: Windows 11 GLFW: v3.3.6

    I have the following source code which create a window on my primary monitor or on my secondary monitor (see lines 25-26). This works well and the monitor is correctly identified with glfwGetWindowMonitor().

    However, if I switch the window of monitor via Windows shortcut: Win+Shift+RightArrow, the glfwGetWindowMonitor() function returns me the wrong monitor (=the monitor where the window was originally created).

    //compile: g++ glfw.cpp -lglfw3 -lgdi32 -lwinmm
    #include <GLFW/glfw3.h>
    #include <iostream>
    #include <windows.h>
    bool closeWindow = false;
    void keyCallback(GLFWwindow* window, int key, int, int, int) {
    	if (key == GLFW_KEY_SPACE) {
    		GLFWmonitor* monitor = glfwGetWindowMonitor(window);
    		if (monitor) {
    			GLFWmonitor* primaryMonitor = glfwGetPrimaryMonitor();
    			MessageBox(nullptr, primaryMonitor == monitor ? "Window on primary monitor" : "Window on secondary monitor", "Monitor name", MB_TASKMODAL | MB_ICONERROR | MB_OK);
    	} else if (key == GLFW_KEY_ESCAPE) {
    		closeWindow = true;
    int main(void) {
    	int width, height, monitorCount;
    	GLFWmonitor* monitor = glfwGetPrimaryMonitor(); //primary monitor
    	//GLFWmonitor* monitor = glfwGetMonitors(&monitorCount)[1]; //secondary monitor (ugly)
    	const GLFWvidmode* mode = glfwGetVideoMode(monitor);
    	GLFWwindow* window = glfwCreateWindow(mode->width, mode->height, "Simple example", monitor, nullptr); //create window in fullscreen
    	glfwSetKeyCallback(window, keyCallback);

    Similar problem:

    • I launch my application on the primary monitor
    • I switch the window to my secondary monitor with shortcut: Win+Shift+RightArrow
    • I minimize the window with shortcut: Win+D
    • I maximize the window by clicking on the icon from the taskbar: the window re-appears on the primary monitor instead of secondary monitor.
    bug Windows 
    opened by petitg1987 1
  • [Feature Request] Support a version of GLFW_MOUSE_PASSTHROUGH that selectively passes mouse events on to the OS

    [Feature Request] Support a version of GLFW_MOUSE_PASSTHROUGH that selectively passes mouse events on to the OS

    I have a case where the window is partially transparent (using GLFW_TRANSPARENT_FRAMEBUFFER), I would like to pass mouse events on if the click was on a transparent portion of the window, and handle them if not. I can determine that in my code, but is there a way in GLFW to catch them and then pass back if I don't want to handle the event?

    GLFW_MOUSE_PASSTHROUGH seems to be all or nothing. When set, even the window decoration buttons are no longer clickable.

    opened by Radagan 3
  • Adding an

    Adding an "install" step to the Compiling GLFW section in documentation

    Adding a step on installing the current build files to the system would immensely help beginners(like me) on installing GLFW. It took me 15min to find out why GFLW isn't working because the documentation didn't mention about installing the build files.

    eg:- Once the GLFW library is compiled, run sudo make install to install GLFW to the system (Or something similar to this)

    I would prefer it added right after the compiling the library part of the documentation.

    (First time reporting an issue so the message might look unprofessional)

    opened by SyllightTheway 0
OBS Linux Vulkan/OpenGL game capture

OBS Linux Vulkan/OpenGL game capture OBS plugin for Vulkan/OpenGL game capture on Linux. Requires OBS with EGL support (currently unreleased, you need

David Rosca 181 Jul 2, 2022
Axel Gneiting 1.3k Jun 24, 2022
C++/openGL/Vulkan 3D engine

DeusEx Machina engine C++/GL/Vulkan 3D graphic engine First commit, hello world! :D Reddit post about why I started with skeletal animation system and

Brais 41 May 19, 2022
OpenGL®-Starter is a template for your upcoming OpenGL Projects which has been compiled to run the most basic Hello World OpenGL Program from LearnOpenGL.com.

OpenGL®-Starter OpenGL®-Starter is a template for your upcoming OpenGL Projects which has been compiled to run the most basic Hello World OpenGL Progr

Kushagra 8 May 27, 2022
The project shows how to hook IDXGISwapChain::Present and capture window frames.

DirectX Present Hook The project is an answer to this Stack Overflow question https://stackoverflow.com/questions/40538590/getting-dxgi-swapchain-by-h

Eugen 6 Jun 2, 2022
SPIRV-Reflect is a lightweight library that provides a C/C++ reflection API for SPIR-V shader bytecode in Vulkan applications.

SPIRV-Reflect SPIRV-Reflect is a lightweight library that provides a C/C++ reflection API for SPIR-V shader bytecode in Vulkan applications. SPIRV-Ref

The Khronos Group 407 Jun 18, 2022
A very stupid window manager.

vswm - very stupid window manager ================================= Probably the most stupid window manager ever created, written over an ancient rel

Felix Hägglund Wennergren 31 Jun 14, 2022
A C++ commandline for use in servers and chat software. Provides very simple asynchronous input/output.

commandline A C++ commandline for use in servers and terminal chat software. Provides very simple asynchronous input/output. Supports reading and writ

Lion 68 Jun 14, 2022
This repository accompanies Ray Tracing Gems II: Next Generation Rendering with DXR, Vulkan, and OptiX

Apress Source Code This repository accompanies Ray Tracing Gems II: Next Generation Rendering with DXR, Vulkan, and OptiX by Adam Marrs, Peter Shirley

Apress 635 Jun 21, 2022
This repo will sort of document my story of learning vulkan with VulkanSDK and cl (msvc) on windows.

Learning Vulkan This repo is a means of documenting my journey with learning Vulkan's basics on windows. Because of the binaries in the LunarG VulkanS

null 2 Dec 8, 2021
Implementation of Peter Shirley's Ray Tracing In One Weekend book using Vulkan and NVIDIA's RTX extension.

Ray Tracing In Vulkan My implementation of Peter Shirley's Ray Tracing in One Weekend books using Vulkan and NVIDIA's RTX extension (formerly VK_NV_ra

Tanguy Fautre 764 Jun 25, 2022
基于 Vulkan 实现的 GPUImage

Vulkan-GPUImage 基于 Vulkan 渲染的 GPUImage 版本,实现渲染链机制,复刻 GPUImage 上的多个效果(逐渐增加中)。 更多技术实现,详见源码~~ Vulkan 学习文章 进击的 Vulkan 移动开发(一)之今生前世 进击的 Vulkan 移动开发之 Instan

glumes 137 Jul 1, 2022
Minimal pathtracer using Vulkan RayTracing

Single File Vulkan Pathtracing Minimal pathtracer using Vulkan RayTracing Environment Vulkan SDK GPU / Driver that support Vulkan Ray Tracin

Yuki Nishidate 25 May 8, 2022
Vulkan physically based raytracer including denoising

VulkanPBRT Vulkan physically based raytracer including denoising. The GPU raytracer is based on Vulkan only, as well as for the denoising only the Vul

null 15 May 26, 2022
A toy renderer written in C using Vulkan to perform real-time ray tracing research.

This is a toy renderer written in C using Vulkan. It is intentionally minimalist. It has been developed and used for the papers "BRDF Importance Sampl

Christoph Peters 250 Jun 27, 2022
Vulkan Minimal Hybrid Rendering

Vulkan Minimal Hybrid Rendering A minimal hybrid rendering sample using ray query Features Rasterization Raytraced shadow Environment Vulkan SDK 1.2.1

Yuki Nishidate 7 Aug 16, 2021
vkfetch is a fetch-program that displays basic information about your vulkan-compatible graphic card(s)!

vkfetch vkfetch is a fetch-program that displays basic information about your vulkan-compatible graphic card(s)! vkfetch will also display some vendor

Wunk 17 May 19, 2022
simple fdtd using vulkan, omp or single thread

fdtd simple fdtd using vulkan, omp or single thread example how to build first clone the repo with: git clone https://github.com/nikisalli/fdtd.git up

Nik 3 Feb 14, 2022
A realtime Vulkan voxel path tracer.

brickmap-vulkan A realtime Vulkan voxel path tracer. This is a work in progress! This system is a Vulkan/SPIRV implementation of the BrickMap by stijn

brandon reinhart 6 Jun 12, 2022