react-x11 2.52.0 → 2.54.0

package/docs/windows-embedding.md

@@ -1,271 +0,0 @@
-# Embedding on Windows: `<Frame>`, `<foreign>`, and being embedded
-
-Three questions, one public API each, and they are **already written**. What
-this page works out is which Windows mechanism sits under each, and what that
-costs — not what to call any of it.
-
-The rule the whole page is written against: **the API does not change.** An
-app writes `<Frame src>`, `<foreign windowId>` and `<window embeddable>` and
-asks `useSupports('embedding')`; which primitive answers is the backend's
-business and nobody else's.
-
-## Where this stands today
-
-**`<Frame src>` is built and works.** Steps 1 and 2 below are what built
-it. The numbers, because the whole point of
-the element is a number:
-
-| the host's event loop, while the pane computes | beats in 9s | median | p95   | worst     |
-| ---------------------------------------------- | ----------- | ------ | ----- | --------- |
-| the pane in its own process                    | 261         | 11ms   | 12ms  | **13ms**  |
-| the same module inline                         | 172         | 11ms   | 114ms | **411ms** |
-
-Same component, same work, mounted two ways. Framed, the host never stalls
-longer than a frame; inline it stalls for a third of a second and loses a
-third of its heartbeats. That is the ticker not breaking stride.
-
-`<foreign>` still refuses here, and still says so:
-
-```
-react-x11: <foreign> needs a backend with cross-process window embedding,
-and this one has none — so nothing can be put in it. Ask
-useSupports('embedding') before rendering one.
-```
-
-which is correct and deliberate — see the section on it below. `<Frame>` no
-longer goes near that path: a backend that composites panes from a shared
-buffer answers `createPaneHost`, and `<Frame>` dispatches on that instead.
-
-Steps 3 and 4 are done too: no pane is forked before anyone asks whether it
-can be shown, and an embeddable window hands out a handle a host can embed.
-What is left is `<foreign>` — the one direction this page recommends _not_
-building — and OLE, which the finding below makes a larger question than it
-looked.
-
-## The two directions are different problems
-
-|                       | who owns the pixels                        | what the other side must be       |
-| --------------------- | ------------------------------------------ | --------------------------------- |
-| `<Frame src>`         | a pane of **our own** app, another process | nothing — we start it             |
-| `<foreign windowId>`  | **another application's** window           | a cooperating or ordinary app     |
-| `<window embeddable>` | **us**, inside somebody else's UI          | a host that knows how to place us |
-
-X11 answers all three with one primitive — reparenting, with XEmbed as the
-handshake — which is why they look like one feature there. Windows has no
-single primitive that covers them, so each needs deciding on its own.
-
-## `<Frame>`: the surface path — how it was built
-
-The seam already exists and is tiny. A backend that composites panes from
-shared memory declares itself with `app.createPaneHost(wnd)`, returning an
-object with three methods (`src/cocoa/panehost.js` is the whole reference
-implementation, 78 lines):
-
-```js
-setRect(rect); // where the pane goes, in the host's window
-present(surfaceId); // the pane published a new buffer; show it
-destroy();
-```
-
-Everything else — the fork, the props channel, the bridged theme, the crash
-fallback, layout and hit testing — is backend-agnostic and already runs here.
-
-On Cocoa `surfaceId` is an `IOSurface`. The Windows counterpart is a
-**DirectComposition surface handle**, and the machinery around it is mostly in
-place already:
-
-- `WindowVisual(windowId)` (windows/src/bridge.h) hands back a window's root
-  DComp visual, and `glcontext.cc` already parents a **child visual** into it
-  for `<glarea>`. A pane host is the same move with different content.
-- `BridgeD3DDevice()` is the shared D3D11 device.
-
-What is missing is the cross-process buffer. Two candidates, and they are not
-equally good:
-
-**`DCompositionCreateSurfaceHandle`** — purpose-built for this. The pane
-creates the handle, makes a composition swapchain against it
-(`IDXGIFactory2::CreateSwapChainForCompositionSurfaceHandle`), and draws; the
-host opens it with `IDCompositionDevice::CreateSurfaceFromHandle` and hands it
-to a visual with `SetContent`. It is an NT handle, so it crosses processes
-with `DuplicateHandle` like any other. This is the path Chromium uses for
-out-of-process content, and the flip is the composition engine's rather than
-ours — no explicit synchronisation to get wrong.
-
-**A shared DXGI texture** — `IDXGIResource1::CreateSharedHandle` on the pane
-side, `ID3D11Device1::OpenSharedResource1` on the host's. More general, and it
-puts synchronisation back on us: a keyed mutex or a shared fence per frame,
-which is a class of bug the first option does not have.
-
-**Recommendation: the DComp surface handle.** It matches how the rest of this
-backend already presents, it needs no fence protocol across the process
-boundary, and `present(handle)` then means what `present(iosurfaceId)` means
-on Cocoa — "this buffer is the current one" — which keeps the seam honest
-rather than only similar.
-
-The one real question a spike had to answer: the pane process must create
-DComp objects, which means a **D3D device of its own**. Two devices, one
-adapter; the handle is shared, the devices are not.
-
-**Answered: the pane keeps the bridge unchanged.** `start()` already builds
-this process's devices, the pane calls it like any other process, and the
-handle crosses. What the spike also turned up, and what no document states,
-is two facts the implementation rests on — both now asserted by the bridge's
-`test/pane.js`, because both fail silently:
-
-- **A pane's back buffer is two frames stale.** A flip chain recycles
-  buffers rather than keeping a bitmap, so a pane repainting only its damage
-  leaves the rest of itself showing frame N-2. Five presents, the fifth
-  touching one corner: the rest came back as the third. The pane window
-  therefore repaints this frame's damage _and_ the last frame's
-  (`STALE_FRAMES`, src/win32/panewindow.js), as one clipped pass over their
-  bounding box — one pass and not one per rect, because two passes over the
-  same pixel composite it twice and a translucent node painted twice is the
-  wrong colour.
-- **A pane has to be clipped to its rect.** The two sides disagree about a
-  pane's size for as long as a round trip takes, and every shrink of a
-  `<Frame>`'s box is one of those. Unclipped, the frames in between paint at
-  the old size over whatever is beside the pane; `paneSetRect` now sets the
-  visual's clip, so a pane that has not caught up is short of its corner
-  instead.
-
-## `<foreign>`: child HWNDs, and why it is the least attractive of the three
-
-`SetParent` across processes works, and it is the closest thing Windows has to
-reparenting. It is also the one the platform warns about, and the warning is
-real: parenting across a process boundary attaches the two threads' input
-queues, so a hung child hangs the parent's input — docs/windows.md already
-says this of `<foreign>` and it is the reason to be slow here.
-
-It is worth noting what the X11 version is used for (docs/embedding.md): a
-terminal pane, a video surface, a docked tray icon, a control-panel applet.
-On Windows the first two are better served by other things — a terminal is a
-pseudoconsole this app can render itself, and video is a swapchain — and the
-last two do not exist as embeddable objects at all.
-
-**Recommendation: leave `<foreign>` refusing on Windows.** It already refuses
-honestly, `useSupports('embedding')` already says so, and a `SetParent`
-implementation would buy a narrow set of cases at the cost of handing any
-embedded program the ability to freeze the host. Revisit if a concrete need
-turns up; do not build it speculatively.
-
-## `<window embeddable>`: being the guest
-
-This is the one the API is most ready for and the one with the most choices
-under it. The prop already means exactly the right thing — "created, not
-shown; somebody else will place me" — and core already honours it on every
-backend by not mapping the window.
-
-**As a child HWND — measured, and it does not work.** This was the
-recommendation on this page, and it is wrong. A composition target bound to
-one of our windows **stops presenting the moment that window becomes a
-child**, and the guest goes blank. Three ways of asking, one answer:
-
-| what was tried                                      | the guest's own pixels |
-| --------------------------------------------------- | ---------------------- |
-| top-level, composed, drawn — the baseline           | **30800 / 30800**      |
-| …then `SetParent` into another window as `WS_CHILD` | 0 / 30800              |
-| created, reparented, and composed only _afterwards_ | 0 / 30800              |
-| the same again without `WS_EX_NOREDIRECTIONBITMAP`  | 0 / 30800              |
-
-So it is not an ordering mistake and not the no-redirection style: a
-DirectComposition target wants a top-level window. Reading the _host_ back
-cannot see this either way — a child's composition tree is its own and
-`PrintWindow` on the parent never contains it — which is why the numbers
-above are the guest's own pixels, with a screen capture agreeing.
-
-What a child HWND would cost, then, is not `SetParent`: it is **a second
-presentation path** for embeddable windows, drawing through a redirection
-bitmap instead of a composition surface. That is not a flag. It is
-`beginDraw` per damage rect, `scrollRegion`, transparency and rounded popups
-— the whole surface model this backend is built on — written again, for the
-one case that cannot have the first one.
-
-**What to do instead: publish the buffer, not the window.** The pane
-mechanism already built for `<Frame>` is the answer, pointed the other way: a
-guest makes a composition surface handle, draws into it, and hands the handle
-out; the host binds it to a visual in its own tree. It exists, it is tested,
-it needs no reparenting, and it does not attach the two processes' input
-queues — so the input-queue caveat that makes `<foreign>` unattractive here
-does not apply to the guest direction at all.
-
-It asks something of the host: the host must be able to bind a composition
-surface, which WinUI 3, another react-x11 app, a DComp-based Electron host
-or a game editor can, and a plain Win32 or OLE document host cannot. That is
-the real trade, and it is a better one than a second renderer.
-
-The open question was the **API**, not the mechanism. X11's guest hands out a
-window id from `windowIdOf(ref)`; Windows' would hand out a buffer handle,
-which is the same shape and a different number — "same public API, different
-implementation", exactly as asked. What it needed was a name and a home, and
-that was a decision rather than a build — taken below.
-
-**As an OLE embedding, for actual documents.** "Embed into a Windows document"
-in the literal sense — a pane inside a Word or Outlook document — is OLE
-Compound Documents: register a CLSID, implement `IOleObject`,
-`IOleInPlaceObject`, `IViewObject2` and `IDataObject`, and in-place activation
-gives us a child HWND in the host's document, which is the previous paragraph
-with a large COM preamble in front of it.
-
-It is a real answer to a real question, and it is a lot: a registered local
-server, apartment discipline, and a storage format for the "not currently
-activated" state (a document has to show _something_ when the object is not
-running — a metafile or a bitmap, which `window.snapshot()` can already
-produce). Worth its own decision, not worth folding into this one.
-
-**Built: `windowHandleOf(ref)` / `useWindowHandle(ref)`.** `<window
-embeddable>` already meant the right thing on every backend; this is the
-number that goes with it, and it is deliberately not `windowIdOf` — on X11
-the two are the same, and that is exactly why nobody noticed they were two
-questions.
-
-| backend       | what it hands out                               |
-| ------------- | ----------------------------------------------- |
-| X11           | the XID — the same number in any process        |
-| Windows       | a composition surface handle, valid in the host |
-| anything else | `null`, which is the capability                 |
-
-An embeddable window on Windows is therefore not an HWND at all: it is the
-same shared buffer a `<Frame>` pane draws into, and `createRoot({ win32: {
-paneHostPid } })` names the host when it is not the parent process. An app
-writes the same thing everywhere and passes the number out of band, as an XID
-is passed; what the host does with it is the host's business.
-
-OLE, if it is ever wanted, is a separate question about a host that cannot
-bind a surface, not a variation on this one.
-
-## What must not change
-
-- `<Frame src>` stays one element that works on every backend, with the same
-  `props`, `fallback` and `restart()`.
-- `useSupports('embedding')` stays the question an app asks before rendering
-  `<foreign>`, and stays false here until something answers it.
-- `<window embeddable>` keeps meaning "created, not shown" everywhere.
-- Nothing grows a Windows-only name. A DComp surface handle is what
-  `present()` carries here, the way an IOSurface id is what it carries on
-  macOS — the seam names neither (AGENTS.md, "Vocabulary").
-
-## Order of work
-
-1. ~~**Spike the two-device question**~~ — **done.** The pane creates its own
-   D3D11 device through the ordinary `start()`, and the handle crosses. It
-   also turned up the two silent facts above.
-2. ~~**`Win32PaneHost`**, against the existing three-method seam~~ — **done**,
-   with `examples/frame.jsx` as the acceptance test and the table at the top
-   of this page as its result. `src/win32/panewindow.js` is the pane's half,
-   `src/win32/panehost.js` the host's, and `windows/src/pane.cc` the eight
-   exports under them.
-3. ~~**Do not fork a pane that cannot be shown.**~~ — **done.** `<Frame>` now
-   asks before the fork: `createPaneHost` or `canEmbed`, either of which is a
-   way to show a pane, and neither of which needs a process to find out.
-   Backend-agnostic, and `test/frame-capability.test.js` holds all three
-   answers.
-4. ~~**Publish an embeddable window's buffer handle**~~ — **done.**
-   `windowHandleOf(ref)` / `useWindowHandle(ref)`, answering an XID on X11
-   and a surface handle here, with `test/window-handle.test.js` holding the
-   difference. Not its HWND, which the table above rules out.
-5. OLE, if a document embedding is actually wanted — and now a bigger
-   question than it looked, because in-place activation renders into a child
-   HWND and this backend cannot draw into one.
-
-Steps 1 and 2 are what made `<Frame src>` mean the same thing on three
-backends. Everything after them is new ground.

package/docs/windows-gl.md

@@ -1,221 +0,0 @@
-# 3D graphics on Windows
-
-**Status: a report, with one measurement that changes the plan.** Written
-2026-09-19 against react-x11 2.16.1 on Windows 11 build 26200, with a GeForce
-GTX 1080 Ti. [windows.md](windows.md) is the backend's design record and said
-`<glarea>` is ANGLE; this is the report that asked whether it has to be.
-
-## What react-x11's 3D story actually is
-
-`<glarea>` is **a GL surface in the layout and nothing above it**
-([gl.md](gl.md)). The scene graph — meshes, materials, lights,
-post-processing — is `@react-x11/components/three`, which brings its own
-reconciler and renders through that surface. So "3D support" on a backend is
-one question: can `onDraw` be handed a working GL context, and can what it
-draws reach the screen composited with everything else?
-
-Three answers ship today, and they are different APIs rather than three
-spellings of one:
-
-|                    | how it draws                                                                                                                    | shaders                                     |
-| ------------------ | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- |
-| **direct** (X11)   | GLES 2 on the GPU via the `x11-dri` addon; frames reach the server as dma-buf over DRI3 + Present, or over Apple-DRI on XQuartz | yes                                         |
-| **indirect** (X11) | GL commands encoded into the X connection                                                                                       | no — the protocol encodes no shader objects |
-| **Cocoa**          | the same `x11-dri` CGL context, rendering into IOSurfaces presented as a `CALayer` sublayer                                     | yes                                         |
-
-The shape worth noticing: **`x11-dri` is not an X11 thing.** It is the GL
-addon, and the Cocoa backend uses it with the X-specific half swapped out.
-wayland.md's open question 4 already anticipated renaming it to a
-display-server-neutral GL addon; Windows is the third platform that would want
-it, which turns that open question into a decision worth taking.
-
-## What Windows can give, measured
-
-`scripts/win32-probe.jsx`'s sibling in the bridge, `glProbe()`, creates a
-throwaway window, sets a pixel format, and asks. On this machine:
-
-```
-vendor          NVIDIA Corporation
-renderer        NVIDIA GeForce GTX 1080 Ti/PCIe/SSE2
-version         4.6.0 NVIDIA 582.66      (core profile)
-glsl            4.60 NVIDIA
-maxTextureSize  32768
-extensions      392
-```
-
-That is **OpenGL 4.6 core out of `opengl32.dll`, with nothing shipped**. It is
-the measurement that matters, because docs/windows.md's plan — ANGLE, two DLLs
-beside the app — was written on a Mac from Microsoft's documentation and from
-what the browsers do, and the browsers ship ANGLE for reasons that are theirs
-rather than ours: they must run identically on every driver, including the
-broken ones, and they sandbox the GPU process.
-
-The catch, and it is the whole reason ANGLE keeps a rung below: **without a
-vendor driver, `opengl32.dll` is the 1.1 software rasterizer.** That is a
-virtual machine with no passthrough, a CI runner, a fresh install before
-Windows Update has fetched the driver, and some remote-desktop sessions. GL
-1.1 has no shaders, no framebuffer objects and no vertex buffers — it is not
-a degraded direct backend, it is the indirect backend's feature set with none
-of its portability.
-
-## The recommendation: a ladder, not a choice
-
-The same discipline the desktop integrations follow — find the mechanism,
-report an honest feature set, degrade in the right direction:
-
-1. **WGL** — `wglCreateContextAttribsARB` for a 3.3-or-better core context on
-   the vendor's driver. This is the rung that answers on an ordinary desktop,
-   and it ships nothing. GLSL, framebuffer objects, vertex buffers,
-   instancing: everything the direct backend's contract promises.
-2. **ANGLE** — EGL and GLES 2/3 over Direct3D 11, two DLLs beside the app, an
-   `optionalDependency` the way `x11-dri` is. It answers where WGL's version
-   probe comes back below 3.3, which is exactly the driverless case. D3D11
-   has a WARP software device, so this rung works on a CI runner where WGL
-   does not.
-3. **nothing**, said plainly — `onError` with a message that names what is
-   missing, which is what `<glarea>` already does on this backend today.
-
-Reversing 1 and 2 would be defensible and is what a browser would do. It is
-not what this project should do: shipping two DLLs to every app to avoid a
-driver check costs every Windows user the download and the packaging story,
-and react-x11's own rule is that `npm install` never compiles and rarely
-downloads.
-
-## The hard part is presentation, not the context
-
-Getting a GL context is a day. Getting its output onto the screen _composited
-with the rest of the window_ is the design problem, and Windows makes it
-harder than either shipped backend does.
-
-The window's content is a DirectComposition surface, and a GL context cannot
-draw into one. Three ways out were on the table:
-
-- **A child HWND with its own context.** This looks like the X11 model
-  exactly: a `<glarea>` there is a child X window on a GL visual, stacked
-  above the parent's content, and `glnodes.js` already positions it from the
-  parent's yoga rect and already knows that a child window cannot be
-  overlapped by the parent's 2D content. The Windows version would be a child
-  HWND with a pixel format and a WGL context, and `SwapBuffers` on its own
-  DC. Cheapest by far, and it reuses the node layer's existing shape rather
-  than inventing one.
-
-  **It does not work, and this was built and measured before that was
-  believed.** A window that presents through a DirectComposition target is
-  shown by DWM _from that visual tree_; the window's redirection bitmap — the
-  surface a child HWND's pixels go to — is not part of what is composited.
-  So the child was invisible with the composition tree above it, invisible
-  with the tree below it (`CreateTargetForHwnd`'s `topmost` argument, both
-  ways), invisible with the window created without
-  `WS_EX_NOREDIRECTIONBITMAP` so that a redirection bitmap existed at all,
-  and invisible through a transparent hole punched in the 2D layer over its
-  rect — that hole showed the desktop. The GL side was healthy throughout:
-  with the 2D layer silenced, the same frame appeared in full.
-
-  There is no ordering that puts the two together, because they are not two
-  layers of one thing.
-
-- **`WGL_NV_DX_interop2`** — render GL into a texture shared with the D3D11
-  device and put that on a composition visual. This is the one that
-  composites properly. docs/windows.md flags it as "a driver's promise rather
-  than the system's": it is present on NVIDIA and AMD, absent on some Intel
-  configurations, and absent from WARP.
-- **ANGLE into a composition swapchain**, which is docs/windows.md's plan and
-  is the only one that is both composited and universal — because ANGLE is
-  already D3D11, so its output is a D3D texture by construction.
-
-**What shipped is the second**, not because it was the plan but because the
-first is not a route. Each surface owns a swap chain made for composition,
-shown by a visual of its own stacked over the window's 2D visual, and the GL
-context draws into a Direct3D texture the frame copies into that swap chain.
-What a child window is on X11 and a subview is on Cocoa, said in this
-platform's terms — and it composites with the window's alpha, which the child
-route would not have.
-
-The consequence for the plan below is that **G5 came first**. ANGLE is still
-the rung this needs for a machine with no vendor driver, for an Intel
-configuration without the interop extension, and for CI on WARP — and it is
-now a _fallback_ under a working composited path rather than the step before
-one.
-
-## How much API is actually needed
-
-Measured against `@react-x11/components` at `3b82678`, the GL map renderer
-(`src/maps/gl/`) uses:
-
-- **64 functions** — `createBuffer`, `bindBuffer`, `bufferData`,
-  `createVertexArray`, `bindVertexArray`, `vertexAttribPointer`,
-  `vertexAttribDivisor`, `drawArraysInstanced`, `createShader`,
-  `shaderSource`, `compileShader`, `createProgram`, `linkProgram`,
-  `getUniformLocation`, the `uniform*` family, `createFramebuffer`,
-  `framebufferTexture2D`, `renderbufferStorage`, `texImage2D`,
-  `texSubImage2D`, `stencilOpSeparate`, `readPixels`, and the state setters.
-- **49 constants.**
-
-That is a **WebGL 2** shape — instancing and vertex array objects are in it —
-over what is, underneath, OpenGL 3.3 core. Sixty-four functions is a bounded,
-mechanical binding job rather than an open-ended one, and it is a fraction of
-WebGL 2's full surface (~150), because a renderer that knows what it is
-drawing does not use all of it.
-
-Note that two naming conventions exist in the tree and both are real:
-`gl.Enable` / `gl.CallList` (the indirect backend's immediate mode, which
-`examples/viewer3d.jsx` is written against) and `gl.enable` / `gl.bindBuffer`
-(the direct backend's WebGL shape). A Windows context implements the second.
-
-## What `three` needs beyond that
-
-`@react-x11/components/three` renders through the same surface, so it needs
-the same context and no more — but it exercises more of the table than the map
-renderer does (cube maps, mipmaps, depth textures, more of the `uniform*`
-family). Budget the full WebGL 2 surface for it rather than the measured 64.
-
-## The plan
-
-- **Phase G0 — the probe.** `glProbe()` in the bridge, reporting vendor,
-  renderer, version, GLSL and whether a core context could be created. Done;
-  the numbers above are its output. It is also what the ladder branches on.
-- **Phase G1 — a context. Done, though not as written.** A `<glarea>` was to
-  become a child window with a WGL core context. It does not: a window
-  presenting through DirectComposition has no redirection bitmap, so a child
-  HWND composites nowhere and is invisible whatever it draws. The context is
-  made against a hidden window and its output reaches the screen through G5
-  below. `app.chooseGLConfig` answers, so `glnodes.js` takes its existing
-  path. The context is an **ES** one (`WGL_CONTEXT_ES_PROFILE_BIT_EXT`),
-  because the shaders these examples ship are GLSL ES and desktop GLSL 1.10
-  rejects things like `mat3(mat4)` that ES 1.00 allows.
-- **Phase G2 — the table. Done.** Entry points above GL 1.1 come from
-  `wglGetProcAddress`, which is per-context and must be resolved after the
-  context is current. `maps-gl` draws, and so does the `configurator`
-  example's laptop.
-- **Phase G3 — the overlay and the input. Done.** `gloverlay.js`'s panes
-  over the surface — a DirectComposition visual with a premultiplied surface
-  of its own (`src/win32/overlay.js`) — and the rule `glnodes.js` already
-  states: the surface selects no pointer input, so the pointer reaches the
-  tree by propagation. On this backend the surface is a visual rather than a
-  window and selects no input at all, so the second half is free.
-- **Phase G5 — composited GL. Done, and first.** `WGL_NV_DX_interop2` onto a
-  composition visual, because the child-window route above is not a route.
-  It is what makes a `<glarea>` participate in the window's alpha instead of
-  punching a hole in it — and a hole, as it turns out, would not have shown
-  the surface anyway.
-- **Phase G4 — ANGLE as the lower rung**, for the driverless case, for an
-  Intel configuration without the interop extension, and for CI on WARP,
-  behind the same `chooseGLConfig` seam. Now a fallback under a working
-  composited path rather than the step before one.
-
-## Open questions
-
-1. **`x11-dri`'s name, a third time.** windows.md's open question 9 and
-   wayland.md's open question 4 are the same question, and Windows is the
-   platform that settles it: the addon is the GL context and the WebGL-shaped
-   table, and the display system is a parameter. A Windows context could be a
-   fourth backend inside it rather than a second GL addon in `@windowkit`.
-2. ~~**Whether the child HWND is acceptable as the shipped answer**~~ —
-   **settled, and not by taste.** A child HWND is not an answer at all here:
-   `WS_EX_NOREDIRECTIONBITMAP` is what lets the window present through
-   DirectComposition, and DWM drops the redirection bitmap a child window
-   would composite into. The question was whether a hole in the window was
-   acceptable; it turned out a hole would not have shown the surface anyway.
-3. **Which rung CI gets.** WARP gives D3D11 and therefore ANGLE, and gives
-   WGL nothing. If `<glarea>` is to be tested at all on a GitHub runner, G4
-   stops being optional.