react-x11 2.52.0 → 2.53.0

package/docs/permissions.md

@@ -25,26 +25,19 @@ function RecordButton() {
 
 ## The ladder
 
-The [file dialog](filedialog.md)'s shape again, with one rung that answers and
-one that only points:
+Like the [file dialog](filedialog.md)'s, chosen for you — one rung that answers
+and one that only points:
 
 |     |                                  |                                                                                                                                                                                                                 |
 | --- | -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | 1   | **the platform's authorization** | The [cocoa backend](macos.md): macOS's privacy (TCC) status per kind, and the system's own prompt where a framework offers one — `AVCaptureDevice` for the camera and microphone, `CoreLocation`, and the rest. |
 | 2   | **the Settings pane**            | `open x-apple.systempreferences:…` — any Mac, bridge or not. It cannot read a status or raise a prompt; it puts the user in front of the switch, which is all `openPrivacySettings` promises.                   |
 
-**On Linux nothing answers yet.** The freedesktop counterparts are the
-per-device portals (`org.freedesktop.portal.Camera`, `.Location`, …), which
-need no bridge and are
-[#466](https://github.com/sidorares/react-x11/issues/466)'s remaining half.
-Until then a status query says `'unknown'` and a request rejects with a
-**typed** `NoPermissionServiceError` — the signal to keep the feature behind
-the answer, not a crash. `usePermission().available` is that branch as render
-state.
-
-The top rung is never chosen by naming a backend: the call asks the connection
-the tree renders through whether it has an authorization API, and the cocoa
-backend says so by carrying one.
+**On Linux nothing answers yet** (the per-device portals,
+`org.freedesktop.portal.Camera`, `.Location`, …, are not wired up). A status
+query says `'unknown'` and a request rejects with a **typed**
+`NoPermissionServiceError` — the signal to keep the feature behind the answer,
+not a crash. `usePermission().available` is that branch as render state.
 
 ## The vocabulary
 
@@ -146,3 +139,5 @@ the request never prompts, or TCC ends the process. See
 - **`'unknown'` is not `'prompt'`.** An app that treats them alike will show
   an "Allow" button on Linux that rejects when pressed. Branch on `available`
   first.
+
+Design notes: [design/permissions.md](../design/permissions.md).

package/docs/react-features.md

@@ -1,17 +1,12 @@
 # React features
 
-You already know React. This page is about the parts where that knowledge
-transfers unchanged, the parts where it transfers with a caveat, and the
-four places where a habit from the DOM will quietly not work.
+**Everything in React core behaves as documented** — hooks, context, error
+boundaries, `<Suspense>`, `lazy`, `use`, transitions, `<Profiler>`,
+`<StrictMode>`. react-x11 is a normal React 19 renderer, and where React's
+behaviour does not depend on the DOM, it is the same behaviour. This page is
+the caveats, and the four places where a DOM habit quietly does not work.
 
-The short version: **everything in React core behaves exactly as documented.**
-Hooks, context, error boundaries, `<Suspense>`, `lazy`, `use`, transitions,
-`<Profiler>`, `<StrictMode>` — all of it. react-x11 is a normal React 19
-renderer, and where React's behaviour does not depend on the DOM, it is the
-same behaviour.
-
-Everything on this page is also something you can drive by hand — in the
-apps that depend on it rather than in a panel of its own:
+The examples that exercise it:
 
 ```sh
 npm run examples:monitor      # priority: a filter over ~780 live rows
@@ -19,12 +14,6 @@ npm run examples:chat         # <Activity>, useOptimistic, <Suspense>
 npm run examples:timer        # error boundaries, and where a crash is logged
 ```
 
-Those replaced an `examples/react-features.jsx` that had a panel per feature.
-A panel proves the API exists; it cannot show you the choice, because nothing
-in it costs anything. `monitor`'s field is expensive because a process list
-is expensive, and that is the only condition under which deferring it is a
-decision rather than a demonstration.
-
 What differs is anything the DOM used to define for you:
 
 - **Paint timing.** A commit does not put pixels on screen. Frames go out on
@@ -37,25 +26,26 @@ What differs is anything the DOM used to define for you:
 
 ## At a glance
 
-|                                                                            |                                                                            |
-| -------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
-| `useState`, `useReducer`, `useContext`, `useMemo`, `useCallback`, `useRef` | unchanged                                                                  |
-| `useImperativeHandle`, `forwardRef`, `ref` as a prop, ref cleanup          | unchanged                                                                  |
-| `use(promise)`, `use(context)`, `React.lazy`                               | unchanged                                                                  |
-| `useOptimistic`, `useActionState`, `<Profiler>`, custom hooks              | unchanged                                                                  |
-| `useSyncExternalStore`                                                     | unchanged, and the best way to bridge non-React code                       |
-| `useTransition`, `startTransition`, `useDeferredValue`                     | work, and really do stay responsive                                        |
-| `useLayoutEffect` vs `useEffect`                                           | the difference is real — one paint versus two                              |
-| `<Suspense>`                                                               | works; read [Suspense and Activity](#suspense-and-activity) for `<window>` |
-| `<Activity>`                                                               | works; `mode="hidden"` around a `<window>` unmaps it                       |
-| Error boundaries                                                           | work — but **where you put one** decides if the window survives            |
-| `<StrictMode>`                                                             | safe to use; effects are not double-invoked on the first mount             |
-| `useId`                                                                    | works; there is very little here to use it for                             |
-| `createPortal`                                                             | use [`<popup>`](elements.md) instead — see [Portals](#portals)             |
-| `flushSync`                                                                | not exported; you almost certainly do not need it                          |
-| `useFormStatus`                                                            | not wired up                                                               |
-| React Server Components                                                    | not available                                                              |
-| anything imported from `react-dom`                                         | not available — see [Not available](#not-available)                        |
+|                                                                   |                                                                   |
+| ----------------------------------------------------------------- | ----------------------------------------------------------------- |
+| `useState`, `useReducer`, `useContext`, `useRef`                  | unchanged                                                         |
+| `useMemo`, `useCallback`, custom hooks                            | unchanged                                                         |
+| `useImperativeHandle`, `forwardRef`, `ref` as a prop, ref cleanup | unchanged                                                         |
+| `use(promise)`, `use(context)`, `React.lazy`                      | unchanged                                                         |
+| `useOptimistic`, `useActionState`, `<Profiler>`                   | unchanged                                                         |
+| `useSyncExternalStore`                                            | unchanged, and the best way to bridge non-React code              |
+| `useTransition`, `startTransition`, `useDeferredValue`            | work, and really do stay responsive                               |
+| `useLayoutEffect` vs `useEffect`                                  | the difference is real — one paint versus two                     |
+| `<Suspense>`                                                      | works; [around a `<window>`](#suspense-and-activity) it unmaps it |
+| `<Activity>`                                                      | works; `mode="hidden"` around a `<window>` unmaps it              |
+| Error boundaries                                                  | work — but **where you put one** decides if the window survives   |
+| `<StrictMode>`                                                    | safe; effects are not double-invoked on the first mount           |
+| `useId`                                                           | works; there is very little here to use it for                    |
+| `createPortal`                                                    | use [`<popup>`](elements.md) instead — see [Portals](#portals)    |
+| `flushSync`                                                       | not exported; you almost certainly do not need it                 |
+| `useFormStatus`                                                   | not wired up                                                      |
+| React Server Components                                           | not available                                                     |
+| anything imported from `react-dom`                                | not available — see [Not available](#not-available)               |
 
 ## Effects, and the paint boundary
 
@@ -68,27 +58,24 @@ it has a directly observable consequence:
 | `useLayoutEffect`        | one frame, with the corrected value                     |
 | `useEffect`              | one frame with the old value, then a frame with the new |
 
-So an adjustment made in `useEffect` flickers. This is not a timing race you
-can get lucky with — updates from a layout effect are folded into the frame
-being prepared, and updates from a passive effect are not.
+So an adjustment made in `useEffect` flickers, every time: updates from a
+layout effect are folded into the frame being prepared, and updates from a
+passive effect are not.
 
 That holds for a correction computed from React state. One computed from
 **geometry** is a layout behind: a layout effect runs after the commit and
 before the layout pass, so `abs` there is still the previous frame's rect
-(zeros, on mount), and anything measured from it describes the frame
-before. For a size, let the element report it with `onLayout`
+(zeros, on mount). For a size, let the element report it with `onLayout`
 ([below](#measuring-a-node)); for a style that depends on one, write a
 container query ([styling.md](styling.md#container-queries)), which the
-pass answers in the same frame. `scrollIntoView` measures nothing when you
-call it, and neither does the part of a `scrollTo` past the extent the last
-pass measured, which is what `scrollTo(Infinity)` asks for when it follows
-rows this commit added. The pass answers both against the geometry it
-produces, so they are safe here ([elements.md](elements.md#scrolling)).
+pass answers in the same frame. `scrollIntoView` and `scrollTo` — including
+`scrollTo(Infinity)` to follow rows this commit added — are safe here: the
+pass answers them against the geometry it produces
+([elements.md](elements.md#scrolling)).
 
-The same boundary is why an event handler feels instant: react-x11 lands the
-React update caused by a click or a keystroke **before** the frame goes out,
-so the response and the default action paint together rather than a frame
-apart.
+The same boundary is why an event handler feels instant: the React update
+caused by a click or a keystroke lands **before** the frame goes out, so the
+response and the default action paint together.
 
 ```jsx
 // good — `tooTall` and `fits` are React state, so the corrected rows paint
@@ -101,9 +88,8 @@ useLayoutEffect(() => {
 ## Measuring a node
 
 **There is no forced synchronous layout.** Nothing you can call will make
-layout run so you can read the result. This is the DOM habit most likely to
-break on the way over, because in a browser `getBoundingClientRect()` both
-reads _and_ triggers.
+layout run so you can read the result, as `getBoundingClientRect()` does in a
+browser.
 
 A node's `abs` rect (and `getClientRects()`) reports what the **last** layout
 produced. On the very first render of a node, that is nothing yet.
@@ -179,11 +165,10 @@ say (see [Known gaps](#known-gaps)).
 really do keep the UI responsive — React will interrupt a transition render
 to handle an incoming click or keystroke.
 
-What is worth knowing is that **transitions are the mechanism that does
-this**. An ordinary `setState` — from a handler, a timer, a socket callback —
-renders in one uninterruptible pass, however much work it is. If a render is
-big enough to drop a frame, wrapping it in `startTransition` (or deferring
-its input with `useDeferredValue`) is not a micro-optimisation, it is the
+**Transitions are the only mechanism that does this.** An ordinary
+`setState` — from a handler, a timer, a socket callback — renders in one
+uninterruptible pass, however much work it is. If a render is big enough to
+drop a frame, `startTransition` (or `useDeferredValue` on its input) is the
 difference between a responsive window and a frozen one.
 
 ```jsx
@@ -203,17 +188,13 @@ Two smaller notes:
 - A `startTransition` inside a click handler is still a transition. It does
   not inherit the handler's urgency.
 
-react-x11 already classifies X11 input for you: presses, releases, keys,
-focus changes, window close and drops are urgent; pointer motion and
-drag-over are not, which is what keeps a motion burst from flooding the
-renderer. You do not have to do anything to get this.
-
-[`examples/monitor.jsx`](../examples/monitor.jsx) is this paragraph with a
-keyboard on it: a filter over hundreds of live rows, where one keystroke
-changes every row on screen. Without the deferral the caret waits for the
-table; with it the field stays under the fingers and the rows arrive a beat
-later. Two things there are worth copying, and both are one-line mistakes in
-the other direction: the expensive subtree is
+Input is already classified for you: presses, releases, keys, focus
+changes, window close and drops are urgent; pointer motion and drag-over are
+not, which keeps a motion burst from flooding the renderer.
+
+[`examples/monitor.jsx`](../examples/monitor.jsx) is the worked case: a
+filter over hundreds of live rows, where one keystroke changes every row on
+screen. Two things there are worth copying: the expensive subtree is
 `memo`ised (or the urgent render rebuilds it anyway, and deferring buys
 nothing), and no prop that changes on every update — not even a "stale"
 border — is passed into it.
@@ -221,22 +202,18 @@ border — is passed into it.
 ### Bridging non-React code
 
 `useSyncExternalStore` is the right tool for anything that lives outside
-React — a timer, a D-Bus signal, a socket, an ntk event. It is also faster
-here than a hand-rolled `setState` bridge: a store notification is applied
-urgently and lands in the next microtask, where the equivalent `setState`
-waits a turn longer.
-
+React — a timer, a D-Bus signal, a socket, an ntk event — and faster than a
+hand-rolled `setState` bridge: a store notification is applied urgently, in
+the next microtask, where the equivalent `setState` waits a turn longer.
 Every mainstream store (zustand, jotai, valtio, redux, XState) works with no
-adapter for this reason. The [window-manager
-example](../examples/wm.jsx) is the worked case: the WM core is a plain
-store, and the UI subscribes to it.
+adapter. The [window-manager example](../examples/wm.jsx) is the worked
+case: the WM core is a plain store, and the UI subscribes to it.
 
 ## Suspense and Activity
 
-`<Suspense>` works. The one thing to plan for is layout: a hidden subtree
-gives up its space entirely, so the fallback lays out as if the real content
-were not there. **Size your fallback deliberately**, or the window collapses
-to the fallback and jumps back on reveal.
+`<Suspense>` works. Plan for layout: a hidden subtree gives up its space
+entirely, so **size your fallback deliberately**, or the window collapses to
+the fallback and jumps back on reveal.
 
 ```jsx
 <Suspense fallback={<box style={{ height: 240 }} />}>
@@ -251,12 +228,11 @@ something else took focus meanwhile, so a boundary that re-suspends
 mid-edit does not drop the user out of what they were typing. See
 [events.md](events.md#focus-and-visibility) for the rules and the way out.
 
-**Scroll positions come back too.** What a hidden boundary holds is not
-placed while it is hidden — the same as under `display: 'none'` — so a scroll
-pane in it is not clamped to the start of content it no longer lays out,
-reports no `onViewport` or `onScroll` until it is shown, and is shown at the
-offset it was left at. A tab kept mounted under `<Activity>` reopens on the
-row the user was reading.
+**Scroll positions come back too.** A hidden boundary's content is not laid
+out while hidden (as under `display: 'none'`), so a scroll pane in it is not
+clamped, reports no `onViewport` or `onScroll` until shown, and reappears at
+the offset it was left at — a tab kept under `<Activity>` reopens on the row
+the user was reading.
 
 If a `<window>` is inside the boundary, hiding it **unmaps the real window**.
 The window manager treats the reveal as a new window: it may re-place it,
@@ -267,12 +243,11 @@ lost. Prefer suspending _inside_ a window over suspending the window itself.
 `import()` gets inlined — you keep lazy _evaluation_ but get no code
 splitting; see [packaging.md](packaging.md).
 
-`<Activity>` works, and `mode="hidden"` around a toplevel `<window>` reads
-the same way `<Suspense>` does: the window is unmapped, and one mounted
-hidden is never mapped at all — it is created, laid out and kept, but the
-window manager only ever hears about it on the reveal. The same caveat
-applies: what the user did to the window before it was hidden is the window
-manager's to remember, and it may not.
+`<Activity>` works, and `mode="hidden"` around a toplevel `<window>` unmaps
+it the same way; one mounted hidden is created and laid out but never
+mapped until the reveal. The same caveat applies: what the user did to the
+window before it was hidden is the window manager's to remember, and it may
+not.
 
 **Testing Suspense**: a promise that settles outside `act()` is not always
 picked up by an `await act()`, because React throttles the commit when a
@@ -281,11 +256,10 @@ see [testing.md](testing.md).
 
 ## Portals
 
-**Use `<popup>`.** It is what you want in almost every case where the DOM
-would reach for `createPortal`: a `<popup>` is written as an ordinary child
-in your JSX — so it sees context, state and props exactly where you wrote it
-— but it is a real top-level X window, so it escapes its parent's clipping
-and can extend past the window edge.
+**Use `<popup>`** where the DOM would reach for `createPortal`. A `<popup>`
+is an ordinary child in your JSX — it sees context, state and props where
+you wrote it — but a real top-level window, so it escapes its parent's
+clipping and can extend past the window edge.
 
 ```jsx
 <box>
@@ -323,8 +297,9 @@ yourself wanting it, you almost certainly want a second `<window>` or a
 
 ## Where to put an error boundary
 
-Boundaries work exactly as documented. The X11-specific decision is
-**placement**, and it decides whether the user's window survives:
+Boundaries work exactly as documented. The decision specific to a desktop
+renderer is **placement**, and it decides whether the user's window
+survives:
 
 ```jsx
 // good — the window and everything the WM knows about it survives
@@ -403,12 +378,12 @@ and the [hot-reload example](../examples/tasks.jsx), which is
 `flushSync`, `findDOMNode`, `hydrateRoot` and `unstable_batchedUpdates` are
 not part of react-x11.
 
-The trap is not the import error — it is that `react-dom` is a required peer
-of some libraries, so it can end up installed anyway. Then the import
-resolves, and `flushSync()` runs your callback **without flushing anything**,
-because it is talking to a renderer you are not using. If a library depends
-on synchronous flushing, check `npm ls react-dom`. The
-[ecosystem register](ecosystem.md) records which packages hit this.
+The trap: `react-dom` is a required peer of some libraries, so it can end up
+installed anyway. Then the import resolves, and `flushSync()` runs your
+callback **without flushing anything**, because it talks to a renderer you
+are not using. If a library depends on synchronous flushing, check
+`npm ls react-dom`; the [ecosystem register](ecosystem.md) records which
+packages hit this.
 
 **Server Components** are not available: there is no Flight client wired up.
 

package/docs/remote.md

@@ -1,12 +1,9 @@
 # Remote display
 
-This is the case the architecture is categorically better at, and the one
-nothing else on the page has told you about.
-
 A react-x11 app **draws over the wire**. It does not render pixels and ship
 them; it sends X11 drawing requests — rectangles, glyph runs, composites —
-and the X server on the far end turns them into pixels. So "running the app
-somewhere else" is not a feature bolted on top. It is what the protocol is,
+and the X server on the far end turns them into pixels. So running the app
+somewhere else is not a feature bolted on top: it is what the protocol is,
 and the program does not know the difference.
 
 ```sh
@@ -18,13 +15,12 @@ Nothing in the app changes. No VNC, no browser, no streaming daemon, no port
 to forward, no second copy of the UI.
 
 **This is the X11 backend**, and it is the reason X11 stays the flagship
-target rather than becoming the legacy one: the Cocoa, win32 and Wayland
-backends have no wire at all, so nothing on this page applies to them. That
-matters in one specific case — **an app running on a Mac or on Windows and
-drawing somewhere else**. `$DISPLAY` in the environment does not choose the
-backend there; `backend: 'auto'` sees darwin and picks Cocoa, or win32 and
-picks the win32 backend, and the window opens on the local machine. Say
-which you want:
+target: the Cocoa, win32 and Wayland backends have no wire at all, so
+nothing on this page applies to them. That matters in one case — **an app
+running on a Mac or on Windows and drawing somewhere else**. `$DISPLAY` in
+the environment does not choose the backend there; `backend: 'auto'` sees
+darwin and picks Cocoa, or win32 and picks the win32 backend, and the window
+opens on the local machine. Say which you want:
 
 ```sh
 REACT_X11_BACKEND=x11 DISPLAY=thin-client:0 npm start
@@ -37,67 +33,31 @@ and drawing to a Mac's XQuartz is not affected: both ends are X11 already.
 
 ## What it costs, measured
 
-The honest comparison is with pixel streaming (VNC, RDP, a
-`--remote-debugging` browser), because that is what people reach for
-instead. The trade is bytes-per-frame against round-trips-per-interaction.
-
-From `scripts/bench/baseline.json`, which measures against node-x11's
-in-process server — so these are exact protocol costs, not estimates:
-
-| scenario                           | requests | bytes out | replies | stalls |
-| ---------------------------------- | -------- | --------- | ------- | ------ |
-| mount: a window, 40 boxes + labels | 110      | 4.2 kB    | 32      | 0      |
-| 50 filled rounded boxes            | 122      | 6.6 kB    | 7       | 0      |
-| a paragraph of text                | 39       | 6.0 kB    | 7       | 0      |
-| 10 wheel notches over 500 rows     | 224      | 11.2 kB   | 22      | 4      |
-| 5 drag steps of a card of widgets  | 72       | 4.3 kB    | 11      | 0      |
-
-**A whole window appears for about four kilobytes.** A single 1280×800 frame
-of VNC, even well compressed, is tens to hundreds of kilobytes, and it is
-sent again every time anything moves. Scrolling a 500-row table ten notches
-costs 11 kB here because only the damaged strip is redrawn (the
-[scroll-blit path](../AGENTS.md), issue #138); the same scroll under pixel
-streaming is ten full frames. Dragging a card with a background of its own
-is the same trade: each step copies the card where it went and draws the
-strip it uncovered, so its widgets are not drawn again
-([extending.md](extending.md#an-element-that-covers-its-box), issue #681) —
-the five steps in the table would be 24 kB drawn.
-
-What react-x11 pays instead is **latency sensitivity**. Bandwidth is not the
-scarce resource on a link like this — round trips are. A request that waits
-for a reply stalls the pipeline for a full RTT, so on a 60 ms link every
-reply is 60 ms of nothing.
-
-The last two columns are how that is watched, and the difference between
-them is the whole point. `replies` counts requests that carry an answer;
-`stalls` counts the ones whose reply arrived with **nothing pipelined behind
-them** — the request was the last thing sent, so the connection really did
-sit idle for a round trip. A pipelined reply costs a reply and no time: the
-mount's 32 are almost all `InternAtom`, fired off together while the window
-is built, and it stalls on none of them. (The bench's own `settle()` fences
-are a fixed floor in that column, so read growth rather than the absolute
-number.)
-
-So the rule — "avoid round trips", rule 4 in
-[AGENTS.md](../AGENTS.md#protocol-efficiency) — is really "avoid _blocking_
-round trips", which is why atoms, geometry and glyph pages are cached rather
-than re-asked, and why `stalls` is the column to watch on a slow link.
+Bandwidth is small: **a whole window appears for about four kilobytes** of
+requests, and scrolling a 500-row table ten notches costs 11 kB, because
+only the damaged strip is redrawn — where a single frame of pixel streaming
+(VNC, RDP) is tens to hundreds of kilobytes, sent again whenever anything
+moves.
+
+What react-x11 pays instead is **latency**. A request that waits for a
+reply with nothing pipelined behind it stalls the connection for a full
+round trip, so on a 60 ms link every such reply is 60 ms of nothing. That is
+why atoms, geometry and glyph pages are cached rather than re-asked, and
+why the column to watch on a slow link is `stalls`, not `replies`:
 `npm run bench -- --hotspots` attributes them, request by request.
 
-Rules of thumb, from the shape of the protocol rather than from a benchmark
-we have not run:
+Rules of thumb, reasoned from the request and reply counts rather than
+measured over a shaped link:
 
 - **Under ~20 ms RTT** (a LAN, a nearby VPS): indistinguishable from local.
 - **20–80 ms** (a continent away): typing and scrolling stay responsive;
   window mapping and font setup have a visible beat.
 - **Above ~150 ms** or on a lossy link: X11's chattiness starts to show, and
   a pixel-streaming protocol designed for high latency will feel better.
-  This is not a react-x11 limitation, it is X11's, and it is the honest place
-  to say so.
+  This is X11's limit, not react-x11's.
 
-`unverified:` those bands are reasoning from the request/reply counts above,
-not measurements over a shaped link. Measuring them properly means `tc
-netem` between two hosts; if you do it, the numbers belong in this table.
+The per-scenario numbers are in the
+[design notes](../design/remote.md#what-it-costs-measured).
 
 ## `ssh -X` and `ssh -Y`
 
@@ -114,8 +74,7 @@ that does not":
 
 **Prefer `-X`.** react-x11 should work under it — it draws into windows it
 created, which is what untrusted mode is for. If something does not, that is
-a bug worth filing rather than a reason to reach for `-Y`. Most toolkits'
-documentation says "use `-Y` if `-X` misbehaves"; that advice hands every
+a bug worth filing rather than a reason to reach for `-Y`, which hands every
 program on the remote host the ability to read your screen and log your
 keystrokes.
 
@@ -178,15 +137,12 @@ the compositor is willing to expose), and `WM_TRANSIENT_FOR` and the
 `_NET_WM_STATE` work are among the things that survive the trip — see
 [elements.md](elements.md#transientfor--a-window-that-belongs-to-another).
 
-**Native Wayland: not remotely**, and the reason is not effort. Wayland has
-no drawing protocol. A Wayland client allocates a buffer, renders pixels into
-it _itself_, and hands the compositor a handle — there is nothing to send over
-a wire, and no server-side rendering to ask for. The entire premise of this
-page, that drawing crosses the connection, does not exist there. The Wayland
-backend (`backend: 'wayland'`, [wayland-backend.md](wayland-backend.md)) is
-therefore a different program under the same API — it rasterizes locally —
-which is why it is opt-in only and never what `'auto'` picks: on Linux the
-default stays X11, and with it everything on this page.
+**Native Wayland: not remotely.** Wayland has no drawing protocol: a client
+renders pixels into a buffer itself and hands the compositor a handle, so
+there is no drawing to send over a wire. The
+[Wayland backend](wayland-backend.md) rasterizes locally, which is why it is
+opt-in and never what `'auto'` picks: on Linux the default stays X11, and
+with it everything on this page.
 
 **XQuartz notes**, since it is the most common macOS path:
 
@@ -196,7 +152,7 @@ default stays X11, and with it everything on this page.
 - Put `/opt/X11/bin` first on `PATH`. Font family resolution shells out to
   `fc-match`, and Homebrew's fontconfig — which is usually found first —
   ships no macOS system-font aliases, so `sans-serif` resolves to a CJK
-  face. Issue [#86](https://github.com/sidorares/react-x11/issues/86).
+  face.
 
 ## Making it feel better