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

Overview

GLFW

Build status Build status Coverity Scan

Introduction

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.

Dependencies

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.

Changelog

  • Added GLFW_RESIZE_NWSE_CURSOR, GLFW_RESIZE_NESW_CURSOR, GLFW_RESIZE_ALL_CURSOR and GLFW_NOT_ALLOWED_CURSOR cursor shapes (#427)
  • Added GLFW_RESIZE_EW_CURSOR alias for GLFW_HRESIZE_CURSOR (#427)
  • Added GLFW_RESIZE_NS_CURSOR alias for GLFW_VRESIZE_CURSOR (#427)
  • Added GLFW_POINTING_HAND_CURSOR alias for GLFW_HAND_CURSOR (#427)
  • 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)

Contact

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.

Acknowledgements

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
Comments
  • 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.

    ...Bill

    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
  • 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

    Hello,

    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 dryya 33
  • 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
  • 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.

    CODE IM USING TO GO INTO FULL SCREEN:

    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
  • warning C4005: 'APIENTRY': macro redefinition

    warning C4005: 'APIENTRY': macro redefinition

    Hi,

    I have been sitting before this problem for two days now and I don't know how to fix this. I am including glfw3.h in multiple files in my project. For example window.h, openglcontext.h, inputhandler.cpp

    As soon as is use glfw3.h in multiple files I am getting this warning message for every file that includes glfw3.h, even if its transitive through another file and even if the include is in the source file of the included header file. I even made a new VS2022 project and started to copy the files one by one to see where the problem starts.

    C:\Windows Kits\10\Include\10.0.19041.0\shared\minwindef.h(130,1): warning C4005: 'APIENTRY': macro redefinition (compiling source file src\lucy\core\service_locator.cpp) message : see previous definition of 'APIENTRY' (compiling source file src\lucy\core\service_locator.cpp) C:\Windows Kits\10\Include\10.0.19041.0\shared\minwindef.h(130,1): warning C4005: 'APIENTRY': macro redefinition (compiling source file src\lucy\core\game.cpp) message : see previous definition of 'APIENTRY' (compiling source file src\lucy\core\game.cpp) C:\Windows Kits\10\Include\10.0.19041.0\shared\minwindef.h(130,1): warning C4005: 'APIENTRY': macro redefinition (compiling source file src\lucy\renderer\opengl_context.cpp) message : see previous definition of 'APIENTRY' (compiling source file src\lucy\renderer\opengl_context.cpp) ...

    I made sure that:

    • no windows header is included before glfw.h
    • windows.h or minwindef.h are not used at all in my project
    • GLFW_INCLUDE_NONE is defined via a preprocessor directive.
    • if glad (glad 2.0) and glfw are used in the same file, glad is included before glfw

    Another weird thing is, as long as I used precompiled header in VS2022 all was fine. This started when I removed the precompiled header.

    I can provide files or more detailed information about the code on request.

    opened by Tremah 7
  • Hide taskbar/Dock icon and menu bar

    Hide taskbar/Dock icon and menu bar

    This is a feature request to introduce a new API to GLFW to support "accessory" applications; applications with windows, but no taskbar/Dock icon, and no menu bar.

    On MacOS, this internally uses NSApplication.activationPolicy with NSApplicationActivationPolicy[^1].

    • TYPE_REGULAR = NSApplicationActivationPolicyRegular
    • TYPE_ACCESSORY = NSApplicationActivationPolicyAccessory
    • TYPE_BACKGROUND = NSApplicationActivationPolicyProhibited

    [^1]: Only available on macOS 10.9 and above. Must emit GLFW_FEATURE_UNAVAILABLE on previous versions.

    I don't know Windows, but it seems like this has to be done per window. GLFW can save the state internally, and then apply this to all windows. There's the case of an application wanting N windows to have a taskbar icon, and M windows to not have that. This is not achievable on MacOS, but it should be possible to build an API which seamlessly supports this on Windows, without causing issues on MacOS. For instance, if this is a per-window flag/attribute, and not for the entire application, the Cocoa implementation can set the activation policy to Regular whenever a regular window is created, and change it to Accessory when there's only accessory windows open. The application-wide state is useful for the case where there's no windows open. Some applications will prefer the Dock icon and application menu bar to show, while some will not.

    For a per-window state, some applications may even always want the Dock icon to show on MacOS, and may always want at least 1 taskbar icon on Windows.

    I don't know how to implement this for X11 and Wayland.

    Mode:

    1. MacOS: show Dock icon and menu bar. Windows: show taskbar icon. X11/WL: similar.
    2. MacOS: hide Dock icon and menu bar. Windows: hide taskbar icon. X11/WL: similar.

    Possible APIs:

    • GLFW_APPLICATION_TYPE, GLFW_APPLICATION_TYPE_REGULAR, GLFW_APPLICATION_TYPE_ACCESSORY and GLFW_APPLICATION_TYPE_BACKGROUND
    • GLFW_WINDOW_TYPE, GLFW_WINDOW_TYPE_REGULAR, GLFW_WINDOW_TYPE_ACCESSORY and GLFW_WINDOW_TYPE_BACKGROUND
    • glfwShowApplicationIcon(bool)
    • glfwRepresentApplication(bool)
    • glfwSetApplicationType(int)
    • glfwSetWindowType(int)
    glfwInitHint(GLFW_APPLICATION_TYPE, GLFW_APPLICATION_TYPE_REGULAR); // Default
    glfwInit();
    
    glfwSetApplicationType(GLFW_APPLICATION_TYPE_ACCESSORY);
    

    or

    glfwInit();
    glfwWindowHint(GLFW_WINDOW_TYPE, GLFW_APPLICATION_TYPE_REGULAR); // Default
    GLFWwindow* window = glfwCreateWindow(640, 500, "Regular window", NULL, NULL);
    
    glfwSetWindowType(window, GLFW_APPLICATION_TYPE_ACCESSORY);
    glfwSetWindowTitle(window, "Accessory window");
    

    or

    glfwInit();
    glfwWindowHint(GLFW_WINDOW_TYPE, GLFW_APPLICATION_TYPE_REGULAR); // Default
    GLFWwindow* window = glfwCreateWindow(640, 500, "Regular window", NULL, NULL);
    
    glfwSetWindowAttrib(window, GLFW_WINDOW_TYPE, GLFW_APPLICATION_TYPE_ACCESSORY);
    glfwSetWindowTitle(window, "Accessory window");
    

    This feature request spawned from this thread:

    • https://github.com/glfw/glfw/issues/1766#

    Implementing this functionality, will fix that issue, but this feature is not in itself required to fix it.

    opened by ws909 1
  • Missing window shadows for window with transparency

    Missing window shadows for window with transparency

    https://github.com/glfw/glfw/blob/57cbded0760a50b9039ee0cb3f3c14f60145567c/src/cocoa_window.m#L877

    I see there is code to do this on purpose? But why? I would expect that there are always shadows. Not only me, this is also reported elsewhere as bug: https://github.com/kovidgoyal/kitty/issues/2827

    macOS 
    opened by albertz 0
  • Add `glfwSetApplicationIcon`

    Add `glfwSetApplicationIcon`

    Resolves #2041

    Emits GLFW_FEATURE_UNIMPLEMENTED on X11, Wayland and Win32.

    The Cocoa implementation simply selects the largest provided GLFWImage. Tested on MacOS 12.5.

    enhancement macOS 
    opened by ws909 1
  • An extension for WebGPU

    An extension for WebGPU

    While working on a documentation for using WebGPU as a graphics API for native applications in C++, I felt the need to develop a simple GLFW extension: glfw3webgpu

    It boils down to a single function:

    WGPUInstance instance = /* ... */;
    GLFWwindow *window = /* ... */;
    WGPUSurface surface = glfwGetWGPUSurface(WGPUInstance instance, window);
    

    This was the only missing piece to be able never to care about os-specific things in the tutorial.

    I believe it could eventually become part of the GLFW itself, I am just not sure how idiomatic my plateform detection is, feel free if you have any suggestion!

    opened by eliemichel 0
Releases(3.3.8)
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 9 Sep 7, 2022
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 290 Jan 1, 2023
Axel Gneiting 1.5k Dec 31, 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
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 457 Dec 26, 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 7 Nov 1, 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 Sep 27, 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 70 Dec 20, 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 684 Dec 29, 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 862 Dec 31, 2022
Open 3D Engine (O3DE) is an Apache 2.0-licensed multi-platform AAA Open 3D Engine

Open 3D Engine (O3DE) is an Apache 2.0-licensed multi-platform 3D engine that enables developers and content creators to build AAA games, cinema-quality 3D worlds, and high-fidelity simulations without any fees or commercial obligations.

O3DE 5.8k Jan 7, 2023
A legacy OpenGL simulator for OpenGL 4.4, written in C++.

the-ancient-tri A legacy OpenGL simulator for OpenGL 4.4, written in C++. Why? My Uni forces us to use legacy OpenGL (eww!), and I didn't want to lear

Mohammad Issawi 4 Feb 10, 2022
基于 Vulkan 实现的 GPUImage

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

glumes 143 Nov 15, 2022
Minimal pathtracer using Vulkan RayTracing

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

Yuki Nishidate 29 Dec 21, 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 18 Nov 25, 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 290 Dec 19, 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 11 Aug 31, 2022
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 19 Oct 27, 2022