0505eb3b1d
* 🐛 Keep text gradients in place when pasting at the caret Text gradients are stored as fractions of the whole text box. Paste copied those fractions unchanged, so in a box of another size the handles and colours moved away from the pasted text. Copy from the v3 editor now records where each span with a gradient or image fill starts in its text box, and the box size, in the clipboard payload. A new WASM export, text_editor_get_range_origin, gives the start of any text range. Paste at the caret finds where those spans start in the target and rewrites their gradients so the handles keep the same pixel offset from the span. Auto-sized texts use the box size they get when the editor closes. AI-assisted-by: claude-opus-5-5 * 🐛 Rebuild text gradient shaders when the text box resizes Text gradient and image shaders are built into the cached Skia paragraphs against the text box size. A resize with no content change reused those paragraphs, so the colours stayed matched to the old box until a reload. The text now remembers the box size its shaders were built for and lays itself out again when that size changes and a span has a gradient or image fill. Text with only solid fills keeps its cache. AI-assisted-by: claude-opus-5-5 * 🐛 Keep text gradients in place when pasting on the canvas A text selection pasted on the canvas becomes a new text whose box differs from the source, so its gradients moved like they did for caret paste. After adding the new text, lay it out, find where its gradient spans start and move their gradients to keep the same pixel offset from the span, in the same undo step. The range origin export now takes a shape id, so it works on texts that are not being edited. AI-assisted-by: claude-opus-5-5 * 🐛 Keep text gradients in place when pasting copied texts at the caret Text shapes copied whole, rather than as an editor selection, reached the caret paste without any geometry, so their gradients still moved away from the pasted text. A shape copy now records where the gradient and image spans of each selected text start, and the box size, by shape id. Paste joins them in the order of the joined paragraphs, with no origin for texts copied without one. Copied texts each have their own box, so every span origin now carries its own box size instead of one box for the whole payload. AI-assisted-by: claude-opus-5-5
Penpot WASM render
This is the canvas-based WebAssembly render engine for Penpot.
Rust & Emscripten
This project is a Rust crate that targets Emscripten (wasm32-unknown-emscripten).
We use wasm32-unknown-emscripten compilation target:
- It compiles Rust code into WASM
- It generates the JavaScript code (“glue”) to load and run the WASM code
Skia
We use Skia, an Open Source 2D graphics library. In particular, the render engine uses Skia via custom binaries of the rust-skia crate.
How to build
With the Penpot Development Environment running, create a new tab in the tmux.
cd penpot/render-wasm
./build
You can also use ./watch to run the build on every change.
The build script compiles the project and copies the .js and .wasm files to the app that uses each target.
Render targets
The same Rust source produces two artifacts, which differ only in compiler options:
| Target | Tuned for | Cargo profile | Consumed by |
|---|---|---|---|
frontend |
speed | release (-O3) |
frontend/resources/public/js |
export |
size | size (-Oz) |
exporter/resources/wasm |
./build # both targets, frontend first
./build frontend # workspace / viewer renderer
./build export # headless exporter renderer
./watch still follows a single target (frontend unless you pass one),
since watching both would rebuild twice on every keystroke.
Each target keeps its own CARGO_TARGET_DIR (target/<target>), so switching
between them does not invalidate the other's cache. Set BUILD_MODE=release
(or NODE_ENV=production) for an optimized build; the default is debug.
Serialize builds in one checkout
All targets in one checkout share one flock lock stored at
render-wasm/.render-wasm-build.lock. The lock covers dependency setup, the
Cargo build, artifact copy, and target cleanup. If another build or cleanup
already holds the lock, the new process prints a waiting message and starts
only after the first process exits.
The watch command takes the lock for each build, then releases it while it waits for source changes. The lock file stays in the checkout after a build, but the operating system releases its lock when the process exits, including after an error or signal.
The lock applies to one checkout and only to commands that use these scripts.
A manual Cargo build can still write to the same target without taking the
lock. Set RENDER_WASM_LOCK_FILE to the same path in each process when you
make different checkouts share a CARGO_TARGET_DIR. The supported Linux build
environment must provide flock from util-linux; flock --version checks this
dependency.
Use the target cleanup commands instead of running cargo clean on the shared
target/ directory:
./clean frontend # remove target/frontend only
./clean export # remove target/export only
Each target writes its own generated shared.js (the enum discriminants the
CLJS side compiles against) next to the code that imports it — respectively
frontend/src/app/render_wasm/api/shared.js and
exporter/src/app/wasm/shared.js. Neither build writes to the other's paths.
Edit your local frontend/resources/public/js/config.js to add the following flags:
enable-feature-render-wasmto enable this render engine.enable-render-wasm-dpr(optional), to enable using the device pixel ratio.
How to test
We currently have two types of tests:
- Unit tests
cd penpot/render-wasm
./test