choosing-texture-bridge-api
Installation
SKILL.md
Choosing a texture-bridge API
Overview
Three tiers, one decision rule: who owns the offscreen window, and where do frames go? All signatures below are the real, current API — do not improvise names.
Decision Table
| You want | Use | Package |
|---|---|---|
| One offscreen page → Syphon/Spout, library owns the window | await createTextureBridge(options) (async, call after app.whenReady()) |
@napolab/texture-bridge-renderer |
| Your own BrowserWindow + paint loop, full send control | new TextureSender(name, w, h) + sendTextureFromPaintEvent(sender, textureInfo) |
@napolab/texture-bridge-core |
| In-app monitor of a bridge's output (no Syphon hop) | bridge.forwardFrames(target, { extraArgs }) |
method on TextureBridge |
| Forward frames from your own paint loop to a renderer | forwardSharedTexture(textureInfo, target, extraArgs?) |
@napolab/texture-bridge-core/electron |
| Receive external Syphon/Spout into your app (display only) | createSharedTextureReceiver({ senderName, target }) + .start() |
@napolab/texture-bridge-renderer |
| Receive external Syphon/Spout as pixels in JS (analysis/export) | createTextureReceiver({ senderName }) + .start() |
@napolab/texture-bridge-renderer |
| Raw RGBA push without Electron (sanity check / CI) | sender.sendRgbaBuffer(buf, w, h) |
@napolab/texture-bridge-core |
Any window that consumes forwarded or received shared-texture frames uses the same receiving pair: installSharedTextureReceiver() + consumeSharedTexture(handlers) from @napolab/texture-bridge-renderer/client (see receiving-shared-textures skill).