@gjsify/gtk-runtime-win32-x64 0.34.0 → 0.35.0

package/README.md

@@ -141,13 +141,36 @@ both sufficient and the simplest mechanism.
   The GdkWin32 backend is compiled **into** `libgtk-4-*.dll` (GTK4 builds every
   backend in), so there is no separate backend DLL — the caches (`loaders.cache`,
   `gschemas.compiled`, `icon-theme.cache`) + the librsvg backer are the
-  additions. The builder also seeds ANGLE (`libEGL`/`libGLESv2`), but the
-  gvsbuild GTK4 release ZIP ships none, so the bundle carries `epoxy-0.dll` —
-  GL *dispatch* — and no GL *implementation*. On a host with a vendor OpenGL ICD
-  that is invisible; on a GPU-less one (VM, RDP, CI) every `Gtk.GLArea` fails
-  with `No GL implementation is available`. Measured on the win11-gjsify VM;
-  tracked as #1097, with the reasoning in the webgl-on-win32 entry of
-  `status/open-todos.md`. gvsbuild ships the tools this step runs (`gdk-pixbuf-query-loaders`,
+  additions. The bundle carries `epoxy-0.dll` — GL *dispatch* — and **no GL
+  *implementation***; the builder probes for one and records the answer as
+  `manifest.glImplementation` (`--require-gl` makes an empty result fatal, for the
+  promotion that ships one). On a host with a vendor OpenGL ICD that is invisible;
+  on a GPU-less one (VM, RDP, CI) every `Gtk.GLArea` fails with `No GL
+  implementation is available`. Measured on the win11-gjsify VM; tracked as #1097,
+  with the reasoning in the webgl-on-win32 entry of `status/open-todos.md`.
+
+  **Neither obvious way of closing it works as-is**, which is why the bundle still
+  ships none — both measured on 0.34.0:
+  - *ANGLE* (`libEGL`/`libGLESv2`) is what #1097 proposed, and gvsbuild ships none.
+    But adding it would not have helped: this `epoxy-0.dll` is built with **no EGL
+    support at all** (no `epoxy_has_egl` export, no `egl*` entry point), so
+    `gdk_win32_display_get_egl_display()` can never engage. That needs libepoxy
+    rebuilt with `-Degl=enabled` first.
+  - *A desktop ICD in `bin/`* (Mesa's `opengl32.dll` + `libgallium_wgl.dll`) is
+    inert by PLACEMENT: epoxy loads desktop GL with a bare
+    `LoadLibraryA("OPENGL32")`, which Windows answers from the **application
+    directory** and then **System32** — never from `PATH`, the only search the
+    loader's bundle wiring controls. System32's inbox GL 1.1 wins and GTK4 rejects
+    it. Reaching a bundled ICD needs the addon to opt the process into
+    `SetDefaultDllDirectories` + `AddDllDirectory(<bundle>/bin)`.
+
+  **The host-side answer works today** and needs no bundle change: register Mesa as
+  a system OpenGL ICD (`mesa-dist-win`'s `systemwidedeploy.cmd 1` writes
+  `HKLM\…\OpenGLDrivers\MSOGL` → `mesadrv.dll` and leaves the inbox `opengl32.dll`
+  in place as the loader). Measured on the win11-gjsify VM: GDK then reports
+  **OpenGL 4.6, non-legacy**, and `three-geometry-teapot` renders.
+
+  gvsbuild ships the tools this step runs (`gdk-pixbuf-query-loaders`,
   `glib-compile-schemas`, `gtk4-update-icon-cache`, `fc-cache`) in `<prefix>/bin`.
   Each data step is defensive — a missing tree/tool WARNs and continues (the DLL +
   typelib bundle is always produced).

package/gtk/manifest.json

@@ -131,6 +131,19 @@
       "GstApp"
     ]
   },
+  "glImplementation": {
+    "matched": [],
+    "dispatch": [
+      "epoxy-0.dll"
+    ],
+    "patterns": [
+      "/^opengl32\\.dll$/i",
+      "/^libgallium_wgl\\.dll$/i",
+      "/^mesadrv\\.dll$/i",
+      "/^libEGL.*\\.dll$/i",
+      "/^libGLESv2.*\\.dll$/i"
+    ]
+  },
   "licenses": {
     "notice": "THIRD-PARTY-NOTICES.md",
     "dir": "licenses",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gjsify/gtk-runtime-win32-x64",
-  "version": "0.34.0",
+  "version": "0.35.0",
   "description": "Batteries-included GTK/GObject-Introspection runtime bundle for Windows x64 — lets @gjsify/node-gi load gi:// namespaces (GLib/GObject/Gio/cairo/Pango/Graphene/Gdk) with NO gvsbuild/system GTK. Platform-gated (win32/x64 only).",
   "type": "module",
   "license": "MIT",