PHP-GLFW: OpenGL and GLFW bindings that turn PHP into a graphics language

An extension, not a library, and that changes the deployment story

PHP-GLFW is a fully-featured OpenGL and GLFW extension for PHP, and the word extension is doing the real work. It is a native C extension that has to be compiled and installed against your PHP build, not a Composer package you require and go. The repository shows the shape of that: config.m4 and config.w32 for the Unix and Windows build systems, a phpglfw.c and phpglfw.h at the root, and the rest of the extension split into focused C files with matching headers, one per area. You get phpglfw_functions.c for the OpenGL calls, phpglfw_vg.c for the vector graphics layer, phpglfw_math.c for the maths, phpglfw_buffer.c for the buffer objects, phpglfw_texture.c for textures, and separate parsers for OBJ, SVG and VOX files. There is a drawcall assembler with its own file, which is the piece that batches geometry into fewer draw calls, and a generator directory plus stubs directory, which is how the PHP side of the extension stays in step with the C side. The primary language in the repository listing is C, and the site is phpgl.net.

OpenGL 4.1 is the target, and coverage is about 90 percent

The OpenGL support has full native support for OpenGL 4.1 core, bringing GPU-accelerated rendering to PHP, and the readme is careful about two things. The extension targets OpenGL 4.1 but can be built for newer versions as well, and support for OpenGL extensions is limited. The bindings mirror the C API as closely as possible, with adjustments made where required or otherwise nonsensical, and the readme puts the coverage at about 90 percent of the full standard, pointing at GLSUPPORT.md for details. That last number is the one to check before committing, because a graphics codebase of any size will eventually call something outside the covered set. The C API mirroring is a deliberate choice with its own consequence: your PHP code reads like the C documentation, which is good for porting, and it also means the PHP surface is as large and as unforgiving as the C one, with no higher-level layer hiding the state machine.

GLFW supplies the window, the input and the monitors

The GLFW bindings cover the parts of a real application that OpenGL itself does not. You get multiplatform window creation and handling on MacOS, Windows and Linux, support for multiple windows and monitors, and real-time user input handling with keyboard and mouse events, joystick input support and gamepad support. The practical value is that PHP-GLFW is a complete application framework for a graphical program rather than a renderer you have to bolt a window system onto, and the gamepad support in particular is what makes the example games possible. The examples directory in the repository follows a numbered progression, starting with a triangle, then a 3D cube, a textured cube, instancing, OBJ loading, a basic light, text rendering, input and events, two drawcall assembler examples including one with the Sponza scene, and a vector graphics example. There is also a gamecontrollerdb.txt in the examples folder, which is the controller mapping database the gamepad support needs.

A vector graphics layer for people who do not want to write shaders

The vector graphics API is the part of the extension aimed at a developer who wants a picture rather than a pipeline. It allows drawing in an HTML canvas-like manner in PHP, and it uses the same OpenGL context internally, so you can build complex rendering pipelines that mix the vector graphics API with the lower level OpenGL API. The stated uses are quick and intuitive rendering of primitives, numerous helpers for colours, gradients and images, and rendering text with any font, and the readme says outright that it is ideal for quickly creating GUIs. That is the honest use case, because a GUI in a language with no other GUI story is the obvious gap this fills. The helpers are not in the README, so the linked user guide page on creating a VG context is where the actual API surface is documented, and the examples directory holds a vg subdirectory with those examples.

Math in C, buffers in native memory, and overloaded operators

The maths library is written in C and optimized for graphical applications, with the supported structs being Vec2, Vec3, Vec4, Mat4 and Quat, and it includes the most common matrix operations such as lookAt, perspective, inverse and rotate. The integration advantages claimed are high performance, a low memory footprint, overloaded operators for the math structs, and some OpenGL functions accepting math structs directly as arguments. The operator overload is the bit that changes how the PHP reads.

  use GL\Math\Vec2;
  $v3 = Vec2(15, -5) + Vec2(42, 7); // returns Vec2(57, 2)

The buffer objects sit alongside the maths and are described as holding data internally in native types, able to handle large arrays of data with a low memory footprint and very fast, with the data stored internally so it is directly uploadable to the GPU. That is the piece that makes a PHP renderer viable, since copying a vertex array from PHP land into native memory for every frame is otherwise the obvious bottleneck.

Texture loading and the parsers that come with it

The remaining pieces are the ones that turn assets into something you can draw. There is a texture module and a geometry module, and the top level of the repository shows the parsers that come with them, with a phpglfw_objparser for OBJ files, a phpglfw_svgparser for SVG, and a phpglfw_voxparser for VOX, which is the MagicaVoxel format used for voxel models. The textures are described in the readme as coming with loaders, and the promise in the project description is that the batteries are included, with math functions and texture loaders named as the examples of what arrives beyond the raw bindings. The example files show how this is exercised, with a ship_light.obj.zip asset for the lighting example and a phpglfwlogo.png in the examples folder, and a font directory for the text rendering example. The SVG parser is an unusual inclusion for a graphics extension, and it is the sort of thing that saves a lot of work when you want to draw a diagram rather than a scene.

Three platforms, one build badge, and an audio release worth noting

The badges tell you what the project promises and what it tests. The licence badge shows MIT, while the repository listing records a custom licence that GitHub cannot classify, so the LICENSE file is what settles the terms. The PHP versions supported badge says 8.0 to 8.4, and the readme states the extension currently supports PHP 8.x. There are three workflow badges, one for the tests, one for a MacOS installer and one for a Windows build, so the platform matrix is MacOS, Windows and Linux, and the Linux path is the one you build yourself. The recent releases are v2.4.0 from 2026-07-08, v2.3.0 from 2025-09-29 which is labelled as adding audio support, and v2.2.1 from 2024-11-19. The audio release is worth noting because it explains the phpglfw_audio.c and phpglfw_audio.h files in the tree. The last push to the repository was on 2026-07-27. The documentation is published from the repository itself, with mkdocs.yml and mkdocs.insiders.yml at the top level, and the website links to a getting started guide, API docs and the examples.

Editorial conclusion

PHP-GLFW fits a developer who already works in PHP and needs a graphical front end, a scientific visualisation or a game prototype without moving to another language, because the extension ships the windowing, the maths and the buffer handling that would otherwise pull in a C++ toolchain. It does not fit a team that needs the whole OpenGL standard, since the readme puts coverage at about 90 percent and points to GLSUPPORT.md for the details, and it does not fit a deployment that cannot compile a native extension. Before you build on it, read GLSUPPORT.md against the OpenGL calls your renderer actually uses, check that your PHP version falls inside the 8.0 to 8.4 range the badge advertises, and plan for the platform build, since the workflow files cover MacOS, Windows and Linux separately.

Frequently asked questions

Official sources

1. Issues
2. mario-deluna/php-glfw on GitHub
3. Project website
4. README
5. Releases