Motivation
Each render frame currently makes multiple WASM calls: Clay_SetPointerState, Clay_UpdateScrollContainers, reduce, and a post-layout Clay_SetPointerState for hit testing. Each call has JS↔WASM context switch overhead and requires marshaling arguments through shared memory.
While the overhead is likely negligible compared to layout and diffing work, there are two reasons to investigate consolidation:
-
Memory safety: calls that write to opsBuf (pointer state, scroll delta) followed by calls that read from it (reduce) could break if a WASM call triggers memory growth between them, invalidating the DataView.
-
Future proofing: as more pre-layout state is added (drag scrolling, transitions), the number of per-frame calls will grow.
Approach
Profile the current multi-call approach to establish a baseline, then evaluate whether a single consolidated entry point (or packing all per-frame state into the command buffer) yields measurable improvement.
Motivation
Each render frame currently makes multiple WASM calls:
Clay_SetPointerState,Clay_UpdateScrollContainers,reduce, and a post-layoutClay_SetPointerStatefor hit testing. Each call has JS↔WASM context switch overhead and requires marshaling arguments through shared memory.While the overhead is likely negligible compared to layout and diffing work, there are two reasons to investigate consolidation:
Memory safety: calls that write to
opsBuf(pointer state, scroll delta) followed by calls that read from it (reduce) could break if a WASM call triggers memory growth between them, invalidating theDataView.Future proofing: as more pre-layout state is added (drag scrolling, transitions), the number of per-frame calls will grow.
Approach
Profile the current multi-call approach to establish a baseline, then evaluate whether a single consolidated entry point (or packing all per-frame state into the command buffer) yields measurable improvement.