Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

E.2 Clay

The Clay integration lives under udewy/third_party/clay/.

Clay is a single-header C layout library. The udewy integration keeps clay.h behind a small C ABI adapter (udewy_clay.c) because Clay's public API uses C structs, macros, callbacks, and floating-point values that do not map cleanly to udewy's raw integer/pointer extern boundary.

Current backend support:

  • Supported today: x86_64, c, wasm32
  • Desktop drawing is provided by the existing SDL wrapper in the demo
  • Browser drawing currently uses udewy's canvas host functions

Build the local Clay artifacts like this:

python udewy/third_party/clay/setup_clay.py

The setup script downloads clay.h when needed, builds a native shim object, and writes target-specific link bundles under udewy/third_party/clay/artifacts/.

For wasm32, the setup script also compiles the Clay shim to a side .wasm module. That requires a clang WebAssembly linker such as wasm-ld; the browser demo uses that side module for Clay layout.

Import Clay from a udewy program:

import p"../third_party/clay/clay.udewy"

The wrapper exposes a small scalar shim surface: initialize Clay, set pointer state for hover/click hit testing, begin/end a layout, open/close simple colored boxes and text elements, and iterate rectangle/text render commands. Clay measures text through a callback and emits text render commands, but it does not rasterize fonts itself. The demo uses a tiny built-in bitmap font renderer so it stays dependency-free across SDL and browser canvas targets.

# Desktop SDL demo
python -m udewy --target x86_64 udewy/tests/clay/demo_clay.udewy

# Hosted C backend
python -m udewy --target c udewy/tests/clay/demo_clay.udewy

# Browser demo; serving is recommended when wasm side artifacts are involved
python -m udewy --target wasm32 --serve-wasm udewy/tests/clay/demo_clay.udewy

The browser route is an app-style canvas renderer, not an HTML/DOM renderer. It is useful for games, tools, and custom UI surfaces. A future Clay-to-DOM renderer would be the better direction for web pages that should preserve native browser behavior such as accessibility, text selection, forms, and find-in-page.