DEV Community: Sai Chandan Kadarla

A code editor with no : building the playground on canvas</h1> <p>Sai Chandan Kadarla — Thu, 25 Jun 2026 02:03:40 +0000</p> <p>The obvious way to build an in-browser code editor is a <code><textarea></code> (or CodeMirror, or Monaco) on the left and your rendered output on the right. The <a href="https://vel.kadarla.com/play" rel="noopener noreferrer">Vel playground</a> doesn't do that. The editor on the left is <em>drawn</em> — it's Vel widgets rendering text, a caret, and selection onto the same GPU canvas as everything else. There is no DOM text input you can see.</p> <p>That sounds like masochism. Here's why it's the right call, and what it costs.</p> <h2> Why draw the editor </h2> <p>The playground is a single WebGPU canvas. The moment you drop a <code><textarea></code> into it, you have two rendering systems fighting: the browser lays out and rasterizes the textarea its way (its own font metrics, its own subpixel rules, its own scrollbar), and Vel renders everything else its way. They don't match. They especially don't match when you zoom — the canvas content re-rasterizes crisply at the new <a href="https://dev.to/blog/hidpi-crisp-text">device-pixel ratio</a>, and the textarea does whatever the browser feels like. You get a seam right down the middle of your tool.</p> <p>Drawing the editor keeps it one scene. The editor (<code>CodeEditor.cpp</code>) is a Vel widget like any other: it measures and paints syntax-highlighted text through the same FreeType atlas as the rest of the UI, so it's pixel-consistent and stays sharp at any zoom. It scrolls with the same machinery, themes with the same tokens, and lives inside a <code>Splitter</code> next to the preview. One renderer, one look, one zoom behavior.</p> <p>It also keeps focus sane. With a real WebGPU canvas as the app surface, you want keyboard events going to the canvas, not getting eaten by a DOM input layered on top. The editor handles keys directly.</p> <h2> The cost: you own everything a textarea gave you for free </h2> <p>This is the honest part. A <code><textarea></code> is decades of accumulated text-editing behavior you stop getting the instant you draw your own:</p> <ul> <li> <strong>Caret and selection.</strong> Where's the cursor, in glyph terms? Click-to-place has to hit-test against measured glyph advances. Shift-arrow and click-drag selection, selection across wrapped lines, the highlight rectangles — all hand-rolled.</li> <li> <strong>Syntax highlighting.</strong> The editor tokenizes <code>.vel</code> and colors it as it draws. That's not a plugin; it's part of the paint.</li> <li> <strong>IME and clipboard.</strong> This is where I <em>don't</em> reinvent the wheel — I lean on the <a href="https://dev.to/blog/accessible-canvas-ui">semantic layer</a>. The editor projects a <code>TextArea</code> semantic node, and the accessibility mirror mounts a real, invisible overlay input on it. So CJK composition, dictation, and the OS clipboard go through the browser's native machinery on a hidden element, while the canvas renders the visible caret and selection. Drawn surface, native input — you can have both, but only because that projection already existed.</li> </ul> <p>If I'd had to build IME from scratch in C++, this would not have been worth it. The fact that the accessibility work <em>already</em> solved native text input is what made a canvas editor affordable.</p> <h2> One WASM, two boot modes </h2> <p>The neat structural trick: the playground and the live preview are the <strong>same WebAssembly binary</strong>, booted two different ways. <code>playground_main.cpp</code> checks a flag the host sets on <code>window</code>:</p> <ul> <li> <code>index.html</code> → no flag → boots the full playground (editor + console + preview chrome).</li> <li> <code>app.html</code> → sets <code>__velAppMode = 1</code> → boots as a bare app runner that renders a single <code>.vel</code> full-screen.</li> </ul> <p>So I ship one <code>.wasm</code> and get both the IDE and the app host out of it. No second build, no divergence.</p> <p>And the preview pane is the part I'm happiest with: it's not a canvas-in-a-canvas emulation. It's a <strong>real nested <code><iframe src=app.html></code></strong> with its <em>own</em> WebGPU device, mounted via an <code>HtmlView</code> widget. The editor streams your source into it over <code>postMessage</code>; the iframe compiles and renders it, and posts back <code>{velReady}</code> on boot and <code>{velErrors}</code> if compilation fails. That isolation is genuinely useful — your code runs in its own browser context, so a runaway loop or a crash in the previewed app can't take the playground down with it. (This is only possible because the <a href="https://dev.to/blog/one-source-three-gpus-and-a-browser">web build needs no cross-origin-isolation headers</a> — a <code>require-corp</code> policy would have blocked the nested iframe.)</p> <p>The same <code>app.html#src=<base64></code> URL that the preview iframe uses is also what the Share button generates: a standalone, hosted-app link to whatever you wrote. The preview and the share target are the same code path.</p> <h2> Capturing logs from inside the engine </h2> <p>One smaller thing that took more thought than expected: the console tab shows live engine logs. But Vel logs through <code>spdlog</code>, and <code>spdlog</code> is a <em>private</em> dependency of <code>libvel</code> — it's not in the public headers, so the playground can't just attach a sink to it from outside.</p> <p>The fix was to put the capture <em>inside</em> the library: <code>vel::log</code> installs a custom <code>spdlog</code> sink, and exposes a spdlog-free API (<code>recent()</code> / <code>generation()</code>) that the playground polls. So the engine keeps spdlog encapsulated, and the playground gets a live log feed without ever linking against spdlog itself. The console's other tab — Problems — is fed by the <code>{velErrors}</code> messages coming back from the preview iframe. Two log streams, one panel.</p> <p>A 0.5s debounce on the editor's change events drives the recompile, so typing doesn't trigger a rebuild on every keystroke — it waits for you to pause.</p> <h2> Was it worth it? </h2> <p>For a general-purpose web app: no. If you need a text editor on a web page and you're not already rendering everything on a canvas, use Monaco and move on. Reimplementing selection semantics and clipboard behavior is a tax most projects shouldn't pay.</p> <p>For <em>this</em> — a tool whose entire point is showing off a GPU UI engine, where the editor and the thing being edited should look like they belong to the same program — it's exactly right. The editor is the engine drawing itself. And the pieces that would've made it prohibitive (native IME, crisp HiDPI text, header-free iframe embedding) were already built for other reasons, so the editor mostly just <em>composed</em> them.</p> <p>That's the recurring shape of this whole project, honestly: the expensive capability you build for one reason turns out to be the thing that makes the next feature cheap.</p> </article> <article> <h1>use \"header.h\": C++ interop as a language feature, not a binding layer</h1> <p>Sai Chandan Kadarla — Thu, 25 Jun 2026 02:03:14 +0000</p> <p>Every "new UI language" I've tried treats talking to existing code as an afterthought. There's a foreign-function interface bolted on the side: you write an IDL, or a schema, or a <code>extern</code> block, or you marshal everything through strings and JSON at the boundary. Interop is a <em>layer</em> — a place where your nice new language stops and the ugly real world begins.</p> <p>I built Vel the other way around. The single constraint I set on day one was: <strong>you must be able to drop any existing C++ codebase into a <code>.vel</code> file with one line, and call it like it was always there.</strong> Not bindings. Not a boundary. A language feature.</p> <p>Here's what that actually takes in the compiler.</p> <h2> The lexer learned <code>::</code> </h2> <p>A normal DSL lexer doesn't care about <code>::</code>. Vel's does, because the whole interop story hinges on qualified C++ names being first-class tokens, not strings I parse later. So <code>::</code> is a real token type (<code>velc/Lexer.cpp</code>):<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight cpp"><code><span class="n">tokens_</span><span class="p">.</span><span class="n">push_back</span><span class="p">({</span><span class="n">TokenType</span><span class="o">::</span><span class="n">ColonColon</span><span class="p">,</span> <span class="s">"::"</span><span class="p">,</span> <span class="n">startLoc</span><span class="p">});</span> </code></pre> </div> <p>And the parser, when it's reading a name, greedily consumes <code>::</code> segments to build a qualified identifier (<code>velc/Parser.cpp</code>):<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight cpp"><code><span class="k">while</span> <span class="p">(</span><span class="n">check</span><span class="p">(</span><span class="n">TokenType</span><span class="o">::</span><span class="n">ColonColon</span><span class="p">))</span> <span class="p">{</span> <span class="k">auto</span> <span class="n">next</span> <span class="o">=</span> <span class="n">advance</span><span class="p">();</span> <span class="n">name</span> <span class="o">+=</span> <span class="s">"::"</span> <span class="o">+</span> <span class="n">next</span><span class="p">.</span><span class="n">text</span><span class="p">;</span> <span class="p">}</span> </code></pre> </div> <p>That tiny loop is what makes <code>std::vector</code>, <code>myapp::db::fetchAll</code>, and <code>myorg::ui::Theme</code> parse as single names rather than syntax errors. The grammar didn't need a special "FFI call" construct — qualified names just <em>are</em> names, everywhere a name is legal: in expressions, in type annotations, in event handlers.</p> <h2> <code>use</code> is an include, not an import system </h2> <p>There are exactly two <code>use</code> forms, and the lexer tags both with one keyword (<code>use</code> or <code>Use</code>):<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>use "backend/users.h" // raw C++ — emitted verbatim as #include use "widgets/stat.vel" // cross-file vel import — pulls in components </code></pre> </div> <p>The C++ form does the least surprising thing possible: it becomes a <code>#include "backend/users.h"</code> at the top of the generated translation unit. No parsing of the header, no wrapping, no shadow types. velc doesn't try to <em>understand</em> your C++ — it just makes sure it's in scope, and then trusts that the names you use resolve when the C++ compiler runs.</p> <p>That trust is the design. velc is not a C++ frontend and never tries to be. It type-checks the <em>Vel</em> parts — widget props, signal types, the registry — and for anything in a <code>use</code>d header, it emits the call and lets the downstream C++ compiler be the type checker. If you typo <code>myapp::fetchUzers()</code>, you don't get a velc error; you get a normal C++ "no member named" error pointing at the right place. The DSL borrows the host language's type system instead of duplicating a worse copy of it.</p> <h2> State can be any C++ type, including async </h2> <p>Because qualified names work in type annotations, your reactive state isn't limited to primitives. This is a real line of Vel:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>#UserList @users: std::vector<myapp::User> = await myapp::fetchUsers() @filter = "" </code></pre> </div> <p>Three things are happening that only work because interop is in the type system:</p> <ul> <li> <code>std::vector<myapp::User></code> is a type annotation with a template argument and a qualified name — the parser handles all of it because, again, names are names.</li> <li> <code>myapp::fetchUsers()</code> is a qualified call in an initializer expression.</li> <li> <code>await</code> on a call whose result type is a C++ type makes velc emit an <code>AsyncSignal<std::vector<myapp::User>></code>, kicked off with <code>std::async</code> and polled each tick — exposing <code>.loading</code> / <code>.ready</code> / <code>.value</code> / <code>.error</code> to the DSL.</li> </ul> <p>velc emits, roughly, a <code>Signal</code>/<code>AsyncSignal</code> member of <em>your</em> C++ type, initialized by <em>your</em> C++ call. The framework has no idea what <code>myapp::User</code> is. It doesn't need to. Your existing code links into the binary as an ordinary translation unit — same compiler, same flags, same linker — and the generated component holds your types directly. There's no serialization at the boundary because there is no boundary.</p> <p>The same mechanism is why a registry component call compiles to a plain constructor — codegen emits <code>vel::gen::Stat{...}</code> the same way it emits <code>myapp::fetchUsers()</code>. To velc, framework calls and your calls are the same kind of thing: qualified names it resolves to C++ and hands off.</p> <h2> What it costs — and it's a real cost </h2> <p>This is the section that separates the design from a sales pitch. Making C++ a language feature means inheriting C++'s consequences with none of the guardrails a binding layer would have given you:</p> <ul> <li> <strong>There is no safety boundary.</strong> A binding layer is also a <em>firewall</em> — it validates, it sandboxes, it catches type mismatches at the edge. Vel has none of that on purpose. If your <code>use</code>d function dereferences a null pointer, your UI segfaults, exactly like C++ does. The DSL is not memory-safe across the interop line because there is no line. You're writing C++ with a nicer syntax for the view layer, and you own C++'s footguns.</li> <li> <strong>Errors surface one layer down.</strong> A mistake in a qualified call isn't a friendly DSL diagnostic; it's a C++ compiler error in generated code. I keep the generated <code>.vel.cpp</code> readable for exactly this reason, but the failure mode is still "read a template error," not "Vel told you nicely."</li> <li> <strong>No hot-swap of the native side.</strong> Vel hot-reloads <code>.vel</code> files by recompiling and swapping the generated component. But your <code>use</code>d C++ is compiled into the binary — change <code>users.h</code> and you're doing a real rebuild, not a sub-second reload. The interop is static, which is what makes it zero-overhead and also what makes it not live.</li> <li> <strong>It assumes one toolchain.</strong> Because the call sites are literal C++, your backend has to build with the same C++ compiler and ABI as <code>libvel</code>. That's fine for a C++ shop; it's not a polyglot story.</li> </ul> <p>I think it's the right trade for what Vel is for: native apps where your data layer is already C++ (or C, or anything with a C++-callable surface), and you want a dense, reactive view language on top without an integration tax. The interop being unsafe is the same reason it's frictionless — the compiler gets out of the way completely.</p> <p>Every other UI language I've used would make me write a binding for <code>fetchUsers</code>. Vel makes me write <code>await myapp::fetchUsers()</code>. That difference — interop as a keyword instead of interop as a subproject — is the reason the thing exists at all.</p> </article> <article> <h1>Making a canvas-rendered UI a screen reader can actually use</h1> <p>Sai Chandan Kadarla — Thu, 25 Jun 2026 02:02:48 +0000</p> <p>Here's the uncomfortable thing about rendering your UI to a GPU canvas: to a screen reader, you've drawn nothing. There's one <code><canvas></code> element and a blob of pixels. A blind user tabbing through your app hears silence. This is the wall every canvas UI hits — Flutter's web target, Figma, anything game-engine-shaped — and most of them either ship a half-hearted shadow DOM or quietly don't solve it.</p> <p>Vel renders everything on the GPU through <a href="https://dev.to/blog/lume-rendering-engine">Lume</a>, so I had the same problem. The way out was to stop treating the pixels as the UI, and treat them as <em>one projection</em> of it.</p> <h2> One tree, two backends </h2> <p>A Vel widget already knows how to describe itself for layout and paint. The insight was that it can describe itself a second way — not "here's how I look" but "here's what I <em>am</em>": a role, a label, a value, some state. Pixels for the eye; semantics for everything else.</p> <p>So every widget fills out a <code>SemNode</code> in a <code>describe()</code> method, and a single collector walks the tree:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight cpp"><code><span class="k">enum</span> <span class="k">class</span> <span class="nc">SemRole</span> <span class="p">{</span> <span class="n">None</span><span class="p">,</span> <span class="n">Group</span><span class="p">,</span> <span class="n">Text</span><span class="p">,</span> <span class="n">Heading</span><span class="p">,</span> <span class="n">Button</span><span class="p">,</span> <span class="n">Link</span><span class="p">,</span> <span class="n">Checkbox</span><span class="p">,</span> <span class="n">Radio</span><span class="p">,</span> <span class="n">Switch</span><span class="p">,</span> <span class="n">Slider</span><span class="p">,</span> <span class="n">TextField</span><span class="p">,</span> <span class="n">TextArea</span><span class="p">,</span> <span class="c1">// editable — single & multi-line</span> <span class="n">Image</span><span class="p">,</span> <span class="n">ProgressBar</span><span class="p">,</span> <span class="n">Alert</span><span class="p">,</span> <span class="n">List</span><span class="p">,</span> <span class="n">ListItem</span><span class="p">,</span> <span class="p">};</span> <span class="k">struct</span> <span class="nc">SemNode</span> <span class="p">{</span> <span class="n">SemRole</span> <span class="n">role</span> <span class="o">=</span> <span class="n">SemRole</span><span class="o">::</span><span class="n">None</span><span class="p">;</span> <span class="n">std</span><span class="o">::</span><span class="n">string</span> <span class="n">label</span><span class="p">;</span> <span class="c1">// accessible name (button text, field label…)</span> <span class="n">std</span><span class="o">::</span><span class="n">string</span> <span class="n">value</span><span class="p">;</span> <span class="c1">// current value (field text, slider readout…)</span> <span class="kt">bool</span> <span class="n">focusable</span> <span class="o">=</span> <span class="nb">false</span><span class="p">;</span> <span class="c1">// participates in Tab order</span> <span class="kt">bool</span> <span class="n">editable</span> <span class="o">=</span> <span class="nb">false</span><span class="p">;</span> <span class="c1">// mount a real <input> for IME/keyboard</span> <span class="kt">bool</span> <span class="n">checked</span><span class="p">,</span> <span class="n">selected</span><span class="p">,</span> <span class="n">disabled</span><span class="p">;</span> <span class="kt">bool</span> <span class="n">hasRange</span><span class="p">;</span> <span class="kt">float</span> <span class="n">valueMin</span><span class="p">,</span> <span class="n">valueMax</span><span class="p">,</span> <span class="n">valueNow</span><span class="p">;</span> <span class="c1">// slider/progress</span> <span class="n">Rect</span> <span class="n">rect</span><span class="p">;</span> <span class="c1">// logical-pixel bounds == CSS px on the web</span> <span class="kt">int</span> <span class="n">id</span><span class="p">;</span> <span class="c1">// stable for one frame</span> <span class="c1">// …</span> <span class="p">};</span> <span class="n">std</span><span class="o">::</span><span class="n">vector</span><span class="o"><</span><span class="n">SemNode</span><span class="o">></span> <span class="n">collectSemantics</span><span class="p">(</span><span class="n">Widget</span><span class="o">&</span> <span class="n">root</span><span class="p">);</span> </code></pre> </div> <p>The roles are deliberately small and intent-based — they map 1:1 to ARIA/DOM roles on the web and to platform accessibility roles elsewhere. A <code>Btn</code> reports <code>Button</code> with its text as the label. A <code>Slider</code> reports <code>Slider</code> with <code>hasRange</code> and the live <code>valueNow</code>. Decorative containers report <code>None</code> and get dropped from the output entirely, so the semantic tree is <em>flatter and cleaner</em> than the visual tree — assistive tech doesn't care about your spacer boxes.</p> <p><code>collectSemantics</code> walks the widget tree in paint order and produces a flat list, stamping each node with its post-layout rect and a stable id. That flat list is the whole accessibility model. Everything downstream is a consumer of it.</p> <h2> The DOM mirror </h2> <p>On the web, a small JS layer takes that flat list and maintains a <strong>hidden DOM tree</strong> positioned exactly over the canvas — a <code><div role="button"></code> at the button's rect, an <code><input></code> at each editable field, an <code><h2></code> for headings. It's visually invisible (the pixels are the real UI) but it's <em>structurally real</em>: screen readers read it, <code>Tab</code> moves through the <code>focusable</code> nodes in order, and focus rings track the actual element.</p> <p>The <code>editable</code> flag is the one that earns its keep. When a node is editable, the mirror mounts a real, transparent <code><input></code>/<code><textarea></code> over it. That single decision hands you the entire native text stack for free: IME composition for CJK, dictation, autocorrect, the OS clipboard, mobile virtual keyboards. I am not reimplementing input method editors in C++ — I'm letting the browser do what it's extremely good at, on an element the user can't see, while the canvas renders the caret and selection.</p> <p>This is also why the playground's code editor is canvas-drawn rather than a <code><textarea></code>: keeping the visual surface on the canvas lets it render crisply at any zoom and stay one coherent scene, while the hidden mirror still gives it <code>TextArea</code> semantics and real keyboard/IME. You get the rendering control of a canvas and the accessibility of a DOM input, instead of choosing one.</p> <p>A few smaller things that matter and are easy to forget: the framework honors <code>prefers-reduced-motion</code> (the eased transitions collapse to instant), and focus is a first-class widget state, not a paint afterthought — so a keyboard user always sees where they are.</p> <h2> The same projection is machine-readable UI </h2> <p>Here's the part I didn't expect when I started. The semantic tree serializes to compact JSON:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight cpp"><code><span class="n">std</span><span class="o">::</span><span class="n">string</span> <span class="nf">semanticsToJson</span><span class="p">(</span><span class="k">const</span> <span class="n">std</span><span class="o">::</span><span class="n">vector</span><span class="o"><</span><span class="n">SemNode</span><span class="o">>&</span> <span class="n">nodes</span><span class="p">);</span> </code></pre> </div> <p>That JSON is exposed to the page (and to the WASM host) as <code>vel_dump_semantics</code>. It was built for the DOM mirror — but it turns out to be exactly what an <strong>AI agent</strong> needs to operate the UI: read the interface as a small structured document, find the node labeled "Save" by role and label, act on it by id. No screenshot, no pixel-OCR, no vision model guessing at button boundaries. The accessibility tree and the agent-automation tree are <em>the same tree</em>, because both are asking the same question — "what is actually here and what can I do with it?" — that pixels can't answer.</p> <p>It also means the initial HTML is crawlable and the UI degrades to something legible with no JS, which I get without any extra work.</p> <h2> What it costs </h2> <p>The honest tradeoffs:</p> <ul> <li> <strong>Widgets have to opt in.</strong> A widget that forgets to <code>describe()</code> itself is invisible to the mirror exactly the way the raw canvas is. Accessibility isn't automatic — it's a second method every widget owes, and the discipline to fill it in is on the framework author. The registry widgets do; a careless custom widget might not.</li> <li> <strong>It's a projection, so it can drift.</strong> The semantic rect is the widget's logical bounds, recomputed each frame. If a widget lies about what it is, a screen reader believes the lie. There's no pixel-level verification that the mirror matches what's drawn — they're consistent only because they come from the same node.</li> <li> <strong>Coordinate-anchored overlays are fiddly.</strong> Positioning hidden DOM exactly over GPU-drawn rects, across DPR changes and scrolling, is the kind of thing that's correct until a transform sneaks in.</li> </ul> <p>But the result is the one that mattered: a GPU-rendered UI where the screen reader announces real buttons, <code>Tab</code> lands where you'd expect, CJK input works, and an agent can read the whole interface as JSON — all from one extra description per widget. The canvas accessibility wall isn't a law of physics. It's just what happens when pixels are the <em>only</em> thing you project.</p> <p>Next on this front: richer live-region announcements (so toasts and async results get spoken), and per-platform native accessibility backends — the same <code>SemNode</code> tree, but feeding macOS's <code>NSAccessibility</code> and Windows UIA directly instead of only the web DOM.</p> </article> <article> <h1>The frame was fast. The relayout was 65 too slow.</h1> <p>Sai Chandan Kadarla — Thu, 25 Jun 2026 02:02:22 +0000</p> <p>I ported <a href="https://github.com/krausest/js-framework-benchmark" rel="noopener noreferrer">js-framework-benchmark</a>'s protocol onto Vel's core — no window, no GPU, no vsync, pure CPU — because I wanted to know if "compiles to native C++" actually translated into the layout numbers I was assuming it did. Each row is a color swatch, a flexible text label, and a button. I created 10,000 of them and measured.</p> <p>The first number was great. The second number was embarrassing.</p> <h2> What the benchmark found </h2> <div class="highlight js-code-highlight"> <pre class="highlight markdown"><code>| rows | build (tree) | layout (cold) | relayout (warm) | |------:|-------------:|--------------:|----------------:| | 100 | 0.03 ms | 0.04 ms | 0.04 ms | | 1000 | 0.26 ms | 0.30 ms | →19.6 ms← | | 10000 | 1.99 ms | 2.22 ms | → 206 ms← | </code></pre> </div> <p><strong>Build</strong> — constructing 10,000 widgets — costs 2ms. This is where the "native C++" thesis pays off bluntly: C++ allocation crushes JavaScript's <code>createElement</code>. Nothing to do here; it was already faster than the framework I was benchmarking against.</p> <p>Now look at the last column. <strong>Relayout (warm)</strong> is the cost of laying out a tree that <em>did not change</em> — same widgets, same text, same constraints, the steady state you're in every frame while the user just moves the mouse. It cost <strong>206ms for 10k rows</strong>. That's not a 60fps frame; that's three frames dropped to lay out a list that didn't move.</p> <p>And the tell is in the comparison: warm relayout cost <em>the same</em> as the cold pass. Re-laying-out an unchanged tree was doing the full amount of work as laying it out for the first time. That's the signature of zero memoization — every frame, from scratch, as if it had never seen this tree before.</p> <h2> The cost wasn't geometry — it was text </h2> <p>My assumption was that "layout is slow" meant the flexbox math was slow: constraint propagation, two passes, intrinsic sizing. I was wrong, and a profiler said so immediately. The 206ms was almost entirely in one place:</p> <p><code>Text::measure</code> → <code>FreeTypeRasterizer::measureText</code>, which walks each string codepoint by codepoint and asks FreeType for the advance width of every glyph via <code>FT_Load_Glyph</code>.</p> <p>Per frame. For every label. Whether or not the text had changed.</p> <p><code>FT_Load_Glyph</code> is not free — it's loading and scaling a glyph outline to get its metrics. Doing it for every character of every visible string, 60 times a second, on text that is identical to last frame, is pure waste. The geometry math was a rounding error next to it. I'd been optimizing the wrong mental model of where layout time goes.</p> <h2> Two caches, both valid forever </h2> <p>The fix is in <code>engine/src/text/FreeTypeRasterizer.cpp</code> — two process-lifetime caches:</p> <ul> <li> <strong>Per-glyph advance cache</strong>, keyed on <code>(face, pixelSize, codepoint)</code>. A glyph's advance width never changes for a given face and size, so the first time you measure an 'e' at 32px you load it; every 'e' after that is a hashmap hit. This makes even <em>cold</em> layout of varied text fast, because common characters are shared across every string.</li> <li> <strong>Per-string width cache</strong>, keyed on <code>(face, pixelSize, string)</code>. Relayout of unchanged text becomes a single lookup — measure the label once, and every subsequent frame that the text is identical is O(1). It's bounded to 200k entries so that live typing (which generates a new string every keystroke) can't grow it without limit.</li> </ul> <p>The key insight that makes this safe: <strong>these values are immutable.</strong> A glyph advance for a fixed face and pixel size is a constant of the universe; it will never be different. So there's no invalidation logic, no staleness, no cache-coherence problem — the hard part of caching simply doesn't exist here. You compute it once and trust it forever.</p> <p>The result:</p> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th>rows</th> <th>relayout before</th> <th>relayout after</th> <th>speedup</th> </tr> </thead> <tbody> <tr> <td>1000</td> <td>19.6 ms</td> <td>0.30 ms</td> <td>~65×</td> </tr> <tr> <td>10000</td> <td>206 ms</td> <td>2.2 ms</td> <td>~93×</td> </tr> </tbody> </table></div> <p>A 10,000-row list now relays out in ~2ms — comfortably inside a 60fps frame. That's the budget Figma-class apps live in, and it was the difference between "compiles to native, therefore fast" being a slogan and being true.</p> <h2> The other half: don't lay out at all </h2> <p>Caching makes a frame cheap. The bigger win is not running the frame. Vel is damage-tracked: an atomic <code>frameDirty</code> flag, raised by any <code>Widget::markDirty()</code>, gates whether the next frame does anything. When nothing's changed, the app sits in <code>glfwWaitEventsTimeout</code> and uses ~0 CPU — no layout, no paint, no spin. Animating widgets re-arm the flag from their <code>tick()</code>; a static page just sleeps.</p> <p>So the steady state is: idle costs nothing, and when something <em>does</em> change, the relayout it triggers is ~2ms instead of 206ms. Both halves matter. A fast frame you run 60 times a second on an idle app is still a battery fire.</p> <h2> What it costs </h2> <ul> <li> <strong>The string cache trades memory for time, bounded crudely.</strong> 200k entries is a fixed ceiling, not an LRU — it's a backstop against live-typing churn, not a tuned eviction policy. For pathological workloads (millions of unique strings) you'd want real eviction.</li> <li> <strong>It's still a full tree walk.</strong> Relayout re-visits every node; it's just that each visit is now cheap. The honest next step is dirty-subtree layout — skipping subtrees whose constraints and content are unchanged — so a 100k-row tree doesn't pay even the cheap per-node cost. Today the whole tree is re-walked; it's fast enough that I haven't needed to, which is its own kind of answer.</li> <li> <strong>It assumes advances are independent.</strong> The per-string cache works because today a string's width is the sum of its glyphs' advances. HarfBuzz shaping will break that assumption (kerning, ligatures, complex scripts) — the cache key still holds (same string, same width) but the per-glyph cache stops being sufficient on its own.</li> </ul> <p>The meta-lesson is the one I keep relearning: <strong>measure before you optimize, because your intuition about where the time goes is usually wrong.</strong> I'd have happily spent a week making the flex math faster and moved the 206ms to 204ms. The profiler pointed at text measurement in thirty seconds, and a cache with no invalidation logic — the easy kind — bought two orders of magnitude.</p> </article> <article> <h1>Why your HiDPI text is blurry, and the physical-pixel fix</h1> <p>Sai Chandan Kadarla — Thu, 25 Jun 2026 02:01:56 +0000</p> <p>Build a canvas renderer, run it on a Retina display, and the first thing you notice is that your text looks slightly <em>soft</em>. Not broken — just a touch blurry, the way a screenshot scaled up 2× is blurry. Everyone has seen it; fewer people know exactly why, and the why points straight at the fix.</p> <p>When I <a href="https://dev.to/blog/lume-rendering-engine">ripped Skia out of Vel</a> and started rendering text through FreeType myself, this was the first wall. Here's what's actually going on.</p> <h2> The bug is a resolution mismatch </h2> <p>A Retina display has a <code>devicePixelRatio</code> of 2 (sometimes 3). Your window is, say, 800 logical points wide but <strong>1600 physical pixels</strong> wide. The GPU draws at physical resolution; your layout reasons in logical points.</p> <p>Now think about a glyph. The naive path:</p> <ol> <li>You want 16pt text, so you rasterize the glyph into a 16-pixel-tall bitmap.</li> <li>You draw that bitmap into a layout that's measured in logical points.</li> <li>The canvas matrix scales everything by the DPR (2×) to fill the physical framebuffer.</li> </ol> <p>Step 3 is the killer. That 16px glyph bitmap gets stretched to 32 physical pixels by the GPU's bilinear sampler. You rasterized at half the resolution the screen can show, then blew it up. The font hinting, the carefully anti-aliased edges — all smeared across pixels that don't line up. <em>That's</em> the softness. It's not the font; it's that you rendered it for a display half as sharp as the one you're on.</p> <h2> The fix: rasterize at physical pixels </h2> <p>The rule is one sentence: <strong>rasterize glyphs at the size they'll occupy in physical pixels, and draw them 1:1.</strong> For 16pt text on a 2× display, you ask FreeType for a 32-pixel glyph and blit it without scaling. The edges land on real device pixels. It's sharp because nothing resampled it.</p> <p>Concretely, that's why Vel's rasterizer takes a <em>pixel size</em>, not a point size:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight cpp"><code><span class="kt">void</span> <span class="nf">setPixelSize</span><span class="p">(</span><span class="n">std</span><span class="o">::</span><span class="kt">uintptr_t</span> <span class="n">face</span><span class="p">,</span> <span class="kt">float</span> <span class="n">pixelSize</span><span class="p">);</span> <span class="n">GlyphBitmap</span> <span class="nf">rasterize</span><span class="p">(</span><span class="n">std</span><span class="o">::</span><span class="kt">uintptr_t</span> <span class="n">face</span><span class="p">,</span> <span class="n">std</span><span class="o">::</span><span class="kt">uint32_t</span> <span class="n">codepoint</span><span class="p">);</span> <span class="kt">float</span> <span class="nf">advance</span><span class="p">(</span><span class="n">std</span><span class="o">::</span><span class="kt">uintptr_t</span> <span class="n">face</span><span class="p">,</span> <span class="kt">float</span> <span class="n">pixelSize</span><span class="p">,</span> <span class="n">std</span><span class="o">::</span><span class="kt">uint32_t</span> <span class="n">codepoint</span><span class="p">);</span> </code></pre> </div> <p>The renderer computes <code>pixelSize = logicalSize × devicePixelRatio</code> and rasterizes there. The glyph bitmap is an R8 coverage map (one byte of alpha per pixel) sized for the device, and it's drawn at physical resolution with no scale in the matrix. The layout still happens in logical points — measurement uses the subpixel-aware <code>advance</code>, so wrapping and alignment are DPR-independent — but the <em>pixels</em> are always device-native.</p> <h2> The atlas has to be keyed on DPR </h2> <p>Here's the part that bites you if you bolt DPI on later. A glyph atlas is a texture you pack rasterized glyphs into so you upload once and draw many. The obvious key is <code>(face, codepoint)</code>. That's wrong the moment a second DPR shows up.</p> <p>The 'A' at 32px (16pt on a 2× display) and the 'A' at 48px (16pt on a 3× display) are <em>different bitmaps</em>. If the atlas key ignores pixel size, you'll serve a cached 2× glyph to a 3× context and you're blurry again — now intermittently, which is worse than always.</p> <p>So Vel keys everything on pixel size: faces are cached per <code>(path, pixelSize)</code>, advances and glyphs per <code>(face, pixelSize, codepoint)</code>. Each DPR effectively gets its own crisp set of glyphs in the atlas. Move a window from a Retina laptop to an external 1× monitor and the renderer rasterizes a fresh set at the new pixel size; the old ones stay cached in case you drag it back. On the web, the host watches <code>matchMedia</code> for DPR changes (zooming the browser changes <code>devicePixelRatio</code>) and re-rasterizes, which is why Vel re-renders sharply when you Ctrl-+ instead of pixel-doubling like an image.</p> <p>There's a subtlety in the metrics, too. FreeType hands you a face's vertical metrics, and you need a consistent convention for the baseline or text drifts vertically between fonts. Vel follows Skia's convention directly — ascent negative (above the baseline), descent positive:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight cpp"><code><span class="k">struct</span> <span class="nc">FaceMetrics</span> <span class="p">{</span> <span class="kt">float</span> <span class="n">ascent</span><span class="p">;</span> <span class="c1">// negative (Skia convention: above baseline)</span> <span class="kt">float</span> <span class="n">descent</span><span class="p">;</span> <span class="c1">// positive</span> <span class="kt">float</span> <span class="n">leading</span><span class="p">;</span> <span class="c1">// line gap</span> <span class="kt">float</span> <span class="n">lineHeight</span><span class="p">;</span> <span class="c1">// ascender - descender + leading</span> <span class="p">};</span> </code></pre> </div> <p>Matching Skia's sign convention wasn't aesthetic — it meant text that used to be laid out by Skia kept landing on the same baseline after I swapped the rasterizer, so nothing shifted by a pixel when the engine changed underneath it.</p> <h2> What it costs </h2> <p>The honest tradeoffs:</p> <ul> <li> <strong>Memory scales with DPR diversity.</strong> An app dragged across a 1×, a 2×, and a 3× display can hold three rasterizations of the same glyphs. For a UI font that's kilobytes; it's a real cost only with huge glyph ranges (CJK) across many sizes, which is when you'd add atlas eviction. Today the advance caches are bounded but the glyph atlas leans on the fact that UI text uses a small set of sizes.</li> <li> <strong>You must thread DPR everywhere measurement happens.</strong> Logical for layout, physical for raster — get the boundary wrong in one place and you get half-size text or a 2× atlas miss. The discipline is the cost of the sharpness.</li> <li> <strong>No fractional-DPR cleverness yet.</strong> A 1.5× display rasterizes at 1.5× and that's fine; I'm not doing anything special for fractional scales beyond honoring them.</li> </ul> <p>The result is the thing you actually want and rarely think about: text that's pin-sharp on a MacBook, on an external monitor, and in a browser at 150% zoom — the same FreeType path on all three, because "physical pixels" is a rule the whole renderer obeys rather than a per-platform patch.</p> <p>The next text milestone is the harder one: HarfBuzz shaping for kerning and complex scripts (Arabic, Devanagari), where a "string" stops being a sequence of independent glyph advances and measurement gets genuinely expensive — which is exactly the case the <a href="https://dev.to/blog/65x-faster-relayout">layout cache</a> was built to protect.</p> </article> <article> <h1>One source, three GPUs, and a browser: putting a native UI on WebGPU</h1> <p>Sai Chandan Kadarla — Thu, 25 Jun 2026 02:00:10 +0000</p> <p>The Vel playground at <a href="https://vel.kadarla.com/play" rel="noopener noreferrer">vel.kadarla.com/play</a> is the same engine that draws the native macOS app, compiled to WebAssembly and pointed at the browser's GPU. Not a re-implementation, not a canvas2d fallback, not a screenshot service — the literal C++ widget tree, running in your tab, rendering through WebGPU.</p> <p>The surprising part isn't that it works. It's how little code the browser target needed, and one deployment property that makes it genuinely cheap to host.</p> <h2> Dawn is the portability layer, so the browser is just another backend </h2> <p>I wrote about <a href="https://dev.to/blog/windows-one-surface-seam">the platform seam</a> being two functions. The web is the cleanest demonstration of why that design pays off. Native platforms hand the GPU a window handle; the browser binds the GPU to an HTML canvas by CSS selector. So <code>SurfaceWeb.cpp</code> barely does anything:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight cpp"><code><span class="c1">// Web (Emscripten) surface glue. There is no window handle — the surface is</span> <span class="c1">// bound to the "#canvas" element in Surface.cpp. So we only return a non-null</span> <span class="c1">// sentinel so the validity check passes; resize is driven by the JS host.</span> <span class="kt">void</span><span class="o"></span> <span class="nf">attachNativeSurface</span><span class="p">(</span><span class="n">GLFWwindow</span><span class="o"></span> <span class="n">window</span><span class="p">)</span> <span class="p">{</span> <span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">window</span><span class="p">)</span> <span class="k">return</span> <span class="nb">nullptr</span><span class="p">;</span> <span class="k">return</span> <span class="k">reinterpret_cast</span><span class="o"><</span><span class="kt">void</span><span class="o">></span><span class="p">(</span><span class="mh">0x1</span><span class="p">);</span> <span class="c1">// sentinel: "canvas-backed"</span> <span class="p">}</span> <span class="kt">void</span> <span class="nf">resizeNativeSurface</span><span class="p">(</span><span class="kt">void</span><span class="o"></span><span class="p">,</span> <span class="kt">int</span><span class="p">,</span> <span class="kt">int</span><span class="p">)</span> <span class="p">{}</span> </code></pre> </div> <p>The reason this is enough: I build Lume on <strong>Dawn</strong>, Google's WebGPU implementation. Natively, Dawn translates my <code>wgpu::</code> calls to Metal, D3D12, or Vulkan. On the web, Emscripten ships <strong>emdawnwebgpu</strong> — a port of the exact same <code>webgpu.h</code> API that forwards to the browser's <em>real</em> WebGPU device. So the engine code doesn't change. The WGSL shaders don't change. The instanced-rect pipeline that draws every shape doesn't change. They all compile to WASM and talk to a GPU that happens to live behind the browser instead of behind the kernel.</p> <p>There's no <code>#ifdef EMSCRIPTEN</code> in the paint code. The web is a backend, not a rewrite — the same way Windows was.</p> <h2> The blocking loop problem, and the header you don't need </h2> <p>A native app loop is allowed to block. Vel's idle path literally parks the thread in <code>glfwWaitEventsTimeout</code> and burns ~0 CPU until an event arrives. You cannot do that on the web: blocking the main thread freezes the tab.</p> <p>The usual answer is threads — run your loop on a Web Worker, use <code>SharedArrayBuffer</code> to talk to the main thread. But <code>SharedArrayBuffer</code> is the expensive choice, and not for the reason people expect. Since Spectre, browsers only expose it when the page is <strong>cross-origin isolated</strong>, which means you must serve these two headers on every response:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight http"><code><span class="err">Cross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp </span></code></pre> </div> <p>Those headers are quietly hostile. <code>require-corp</code> means every cross-origin resource the page loads — fonts, images, analytics, an embedded iframe — must opt in with its own CORP/COEP headers or it's blocked. It breaks third-party embeds. It means you can't just drop the build on a static CDN and link it. And it makes the playground hard to embed in <em>another</em> page (like the docs).</p> <p>So I went the other way: <strong>single-threaded, with ASYNCIFY.</strong> ASYNCIFY is an Emscripten transform that rewrites the WASM so a "blocking" call can actually unwind the stack, yield to the browser's event loop, and resume later. The engine keeps its natural blocking-loop shape in C++; ASYNCIFY makes that cooperate with the event loop instead of freezing it. No worker, no <code>SharedArrayBuffer</code>, and therefore <strong>no COOP/COEP headers at all.</strong></p> <p>The payoff is operational: the playground is four static files (<code>index.html</code>, <code>index.js</code>, a ~3 MB <code>index.wasm</code>, and an <code>app.html</code>). It hosts on plain Vercel with no special headers, and it embeds in the docs as an ordinary <code><iframe></code>. The preview pane you see is a <em>real</em> nested iframe running its own WebGPU device, with source streamed in over <code>postMessage</code> — which is only possible because nothing requires cross-origin isolation.</p> <h2> HiDPI falls out for free </h2> <p>One detail I like: the canvas backing size is set to <code>CSS size × devicePixelRatio</code> by the JS host, and Surface reconfigures the wgpu surface to match. That's the same physical-pixel rule the <a href="https://dev.to/blog/hidpi-crisp-text">native text rasterizer uses</a> — so text on the web is snapped to device pixels and stays crisp on Retina, using the identical code path as the desktop app. Cross-platform consistency isn't a goal I chase; it's a consequence of there being one renderer.</p> <h2> What it costs </h2> <p>ASYNCIFY isn't free. It instruments the binary, which adds size and a small per-call overhead on the functions that can unwind — you don't want it everywhere, so you scope which calls it applies to. Single-threaded also means exactly that: no offloading layout or decode to a worker, so a genuinely heavy frame has nowhere to hide. For a UI that idles at ~0 CPU and lays out <a href="https://dev.to/blog/65x-faster-relayout">10k rows in ~2 ms</a> that's fine; for a compute-heavy app it would be a real ceiling.</p> <p>And the honest caveat: this is WebGPU, so it needs a recent browser. Chrome and Edge have had it on by default since 113; Safari shipped it; Firefox is partial. A blank canvas almost always means "this browser doesn't have WebGPU enabled," which is a worse failure mode than a 2D fallback would be — I chose fidelity over reach.</p> <p>But the thing I set out to prove held up: porting a native GPU UI to the browser was a 20-line surface file and a build-flag decision, not a parallel web codebase. The hard part of "write once, run everywhere" was never the rendering. It was refusing to let the platforms leak into the parts that aren't platform-specific.</p> </article> <article> <h1>The Windows port that was one 20-line file (and the DLL that wasn't there)</h1> <p>Sai Chandan Kadarla — Thu, 25 Jun 2026 02:00:09 +0000</p> <p>"Cross-platform" usually means a codebase pockmarked with <code>#ifdef _WIN32</code>. You open a file expecting layout logic and instead find three forks of everything: window creation, the GL context, the swapchain, DPI handling. The platform differences leak into every layer because nobody drew a line that says <em>the OS-specific part stops here.</em></p> <p>When I brought Vel to Windows, I wanted to find out how small that line could be. The answer turned out to be two functions.</p> <h2> The seam is two functions </h2> <p>Vel renders through <strong>Lume</strong>, my GPU engine built on Dawn (Google's WebGPU implementation). Dawn already gives me one drawing API that lands on Metal, D3D12, or Vulkan depending on the platform. So the only thing that's genuinely OS-specific is the very first handshake: <em>take a window, hand back something the GPU can present into.</em></p> <p>That's the whole platform contract — <code>engine/src/platform/Platform.h</code>:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight cpp"><code><span class="k">namespace</span> <span class="n">vel</span><span class="o">::</span><span class="n">platform</span> <span class="p">{</span> <span class="c1">// Returns an opaque native handle for the window's render surface.</span> <span class="kt">void</span><span class="o"></span> <span class="n">attachNativeSurface</span><span class="p">(</span><span class="n">GLFWwindow</span><span class="o"></span> <span class="n">window</span><span class="p">);</span> <span class="c1">// Resize the native backing store, if the platform needs one.</span> <span class="kt">void</span> <span class="n">resizeNativeSurface</span><span class="p">(</span><span class="kt">void</span><span class="o"></span> <span class="n">nativeHandle</span><span class="p">,</span> <span class="kt">int</span> <span class="n">widthPx</span><span class="p">,</span> <span class="kt">int</span> <span class="n">heightPx</span><span class="p">);</span> <span class="p">}</span> </code></pre> </div> <p>Everything above this line — the widget tree, layout, paint, the entire engine — is platform-neutral and compiles identically everywhere. <code>engine/src/gpu/Surface.cpp</code> calls <code>attachNativeSurface</code>, gets back a <code>void</code>, and feeds it into the matching <code>wgpu::SurfaceSource</code> descriptor. It never learns what OS it's on.</p> <p>On macOS, that handle is a <code>CAMetalLayer</code> you attach to the <code>NSView</code>. It's the longest of the implementations because Cocoa makes you set up a layer, pick a pixel format, and track the backing scale factor — about 40 lines.</p> <p>Windows is shorter. The whole file:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight cpp"><code><span class="cp">#define GLFW_EXPOSE_NATIVE_WIN32 #include</span> <span class="cpf"><GLFW/glfw3.h></span><span class="cp"> #include</span> <span class="cpf"><GLFW/glfw3native.h></span><span class="cp"> </span> <span class="k">namespace</span> <span class="n">vel</span><span class="o">::</span><span class="n">platform</span> <span class="p">{</span> <span class="c1">// On Windows the wgpu surface binds directly to the window's HWND, so there is</span> <span class="c1">// no intermediate layer to create — we just hand back the GLFW window's HWND.</span> <span class="kt">void</span><span class="o"></span> <span class="n">attachNativeSurface</span><span class="p">(</span><span class="n">GLFWwindow</span><span class="o"></span> <span class="n">window</span><span class="p">)</span> <span class="p">{</span> <span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">window</span><span class="p">)</span> <span class="k">return</span> <span class="nb">nullptr</span><span class="p">;</span> <span class="k">return</span> <span class="k">static_cast</span><span class="o"><</span><span class="kt">void</span><span class="o">></span><span class="p">(</span><span class="n">glfwGetWin32Window</span><span class="p">(</span><span class="n">window</span><span class="p">));</span> <span class="p">}</span> <span class="c1">// No-op: there is no CAMetalLayer-equivalent backing store to resize. The</span> <span class="c1">// swapchain is sized by wgpu::Surface::Configure() in Surface.cpp.</span> <span class="kt">void</span> <span class="nf">resizeNativeSurface</span><span class="p">(</span><span class="kt">void</span><span class="o"></span><span class="p">,</span> <span class="kt">int</span><span class="p">,</span> <span class="kt">int</span><span class="p">)</span> <span class="p">{}</span> <span class="p">}</span> </code></pre> </div> <p>That's it. There's no layer to construct, so <code>attachNativeSurface</code> is one line, and resize is a no-op because the D3D12 swapchain binds straight to the <code>HWND</code> — when the window resizes, <code>wgpu::Surface::Configure()</code> handles it. The asymmetry with macOS isn't sloppiness; it's the platforms being honestly different, contained to the one place where they differ.</p> <p>CMake selects the right file and nothing else changes:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight cmake"><code><span class="nb">if</span><span class="p">(</span>APPLE<span class="p">)</span> <span class="nb">set</span><span class="p">(</span>VEL_PLATFORM_SOURCES engine/src/platform/SurfaceMac.mm<span class="p">)</span> <span class="nb">elseif</span><span class="p">(</span>WIN32<span class="p">)</span> <span class="nb">set</span><span class="p">(</span>VEL_PLATFORM_SOURCES engine/src/platform/SurfaceWin.cpp<span class="p">)</span> <span class="nb">endif</span><span class="p">()</span> </code></pre> </div> <p>The grep that convinced me the design held: there is not a single <code>#ifdef _WIN32</code> anywhere in the framework or registry. The OS forks live in two ~20-40 line files, and the compiler picks one.</p> <h2> The bug that doesn't show up at build time </h2> <p>So the port "worked" almost immediately — it compiled, it linked, the window opened. And then it crashed the first time anything tried to draw text, with a missing-DLL error for a library that was unmistakably present in my vcpkg tree.</p> <p>This is the Dawn-on-D3D12 trap, and it's a good one. Dawn's D3D12 backend compiles shaders at runtime using DirectX's standalone compiler — <code>dxcompiler.dll</code> and <code>dxil.dll</code>. It doesn't link them. It <code>LoadLibrary()</code>s them lazily, the first time it needs to compile a shader.</p> <p>That timing is the whole problem. vcpkg's "applocal" deploy step — the thing that copies your DLL dependencies next to your <code>.exe</code> — works by inspecting the binary's <strong>link-time</strong> import table. But these DLLs were never imported at link time; they get pulled in at <em>runtime</em> by name. So the tooling that's supposed to make Windows binaries portable looks at the executable, sees no dependency on <code>dxcompiler.dll</code>, and faithfully copies nothing.</p> <p>The fix is to stop relying on inference and just copy them, for any Vel app target:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight cmake"><code><span class="nb">function</span><span class="p">(</span>vel_copy_dxc_runtime TARGET<span class="p">)</span> <span class="nb">if</span><span class="p">(</span>NOT WIN32<span class="p">)</span> <span class="nb">return</span><span class="p">()</span> <span class="nb">endif</span><span class="p">()</span> <span class="nb">set</span><span class="p">(</span>_dxc_bin <span class="s2">"</span><span class="si">${</span><span class="nv">VCPKG_INSTALLED_DIR</span><span class="si">}</span><span class="s2">/</span><span class="si">${</span><span class="nv">VCPKG_TARGET_TRIPLET</span><span class="si">}</span><span class="s2">/bin"</span><span class="p">)</span> <span class="nb">foreach</span><span class="p">(</span>_dll dxcompiler.dll dxil.dll<span class="p">)</span> <span class="nb">if</span><span class="p">(</span>EXISTS <span class="s2">"</span><span class="si">${</span><span class="nv">_dxc_bin</span><span class="si">}</span><span class="s2">/</span><span class="si">${</span><span class="nv">_dll</span><span class="si">}</span><span class="s2">"</span><span class="p">)</span> <span class="nb">add_custom_command</span><span class="p">(</span>TARGET <span class="si">${</span><span class="nv">TARGET</span><span class="si">}</span> POST_BUILD COMMAND <span class="si">${</span><span class="nv">CMAKE_COMMAND</span><span class="si">}</span> -E copy_if_different <span class="s2">"</span><span class="si">${</span><span class="nv">_dxc_bin</span><span class="si">}</span><span class="s2">/</span><span class="si">${</span><span class="nv">_dll</span><span class="si">}</span><span class="s2">"</span> <span class="s2">"$<TARGET_FILE_DIR:</span><span class="si">${</span><span class="nv">TARGET</span><span class="si">}</span><span class="s2">>"</span> VERBATIM<span class="p">)</span> <span class="nb">endif</span><span class="p">()</span> <span class="nb">endforeach</span><span class="p">()</span> <span class="nb">endfunction</span><span class="p">()</span> </code></pre> </div> <p>The lesson generalizes past Windows: <strong>any dependency resolved by <code>dlopen</code>/<code>LoadLibrary</code> is invisible to your build graph.</strong> Static analysis of the binary can't find it, so your packaging step won't either. If a library loads plugins, codecs, or — like Dawn — a shader compiler by name at runtime, you own deploying those files yourself. It will pass every test on the dev machine where the DLL happens to be on <code>PATH</code>, and fail on the first clean box.</p> <p>One more Windows-specific wrinkle worth naming: MSVC exports no symbols from a shared library unless you annotate them, and I wasn't about to sprinkle <code>__declspec(dllexport)</code> through public headers that also compile on macOS. CMake's <code>WINDOWS_EXPORT_ALL_SYMBOLS ON</code> generates the export table for the whole <code>libvel</code>, so the showcase and hot-reload plugins link against it the same way they do everywhere else. One property, not a header rewrite.</p> <h2> What it cost, and what it didn't </h2> <p>What the seam buys: adding a platform is a bounded, legible task. I can point at the two functions a new OS has to implement and know that's the entire surface area. Linux is the same shape — an <code>X11</code>/Wayland <code>SurfaceX11.cpp</code> against the same contract — which is why it's a known quantity rather than a rewrite.</p> <p>What it costs: the abstraction is only as portable as Dawn is, and I've inherited Dawn's operational reality — including a shader compiler that loads itself at runtime and a build system that can't see it coming. I traded a pile of <code>#ifdef</code>s for a dependency I don't fully control. For a 2D UI engine that's a good trade; if I needed exotic per-backend GPU features, the seam would start leaking and I'd be writing the <code>#ifdef</code>s after all.</p> <p>But the honest result is the one I wanted: Windows support is a 20-line file and a DLL-copy function, not a fork of the codebase. The interesting work stayed in the engine, where it belongs.</p> <p>Next up is the Linux surface — same contract, X11 first — and then a per-app DLL-deploy helper so the runtime-loaded libraries travel with shipped apps automatically instead of living in the SDK's <code>bin</code>.</p> </article> <article> <h1>Building Vel: A Token-Efficient, Compile-to-Native UI Language</h1> <p>Sai Chandan Kadarla — Sun, 07 Jun 2026 19:42:05 +0000</p> <p>I've been building <strong>Vel</strong> — a new declarative UI language plus the runtime and component registry to back it. The goal is unapologetically ambitious: write production desktop apps with the expressive density of Tailwind classes, the reactivity model of SolidJS, and the rendering quality of Flutter, while letting you call into any existing C/C++ backend without a binding layer.</p> <p>This post walks through the architecture I landed on, why each tier exists, and what the language actually buys you in practice.</p> <h2> The three-tier rule </h2> <p>Most UI frameworks blur three concerns: the language, the runtime substrate, and the opinionated widget set. Vel splits them on purpose, with a strict one-way dependency:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>language → framework → registry → application (velc) (libvel) (vel::ui::) (.vel + main.cpp) </code></pre> </div> <ul> <li> <strong>Language</strong>: a small, indentation-sensitive DSL (<code>.vel</code>) and a single-pass compiler (<code>velc</code>). It parses to an AST, type-checks against a primitive registry, and emits idiomatic modern C++ that consumes the framework.</li> <li> <strong>Framework (<code>libvel</code>)</strong>: the substrate. Widget pipeline (measure / place / paint / tick), Skia-backed Painter, an event dispatcher, the reactive primitives (<code>Signal<T></code>, <code>Computed<T></code>, <code>AsyncSignal<T></code>), and infra (router, storage, net shim, IO, time, validate, notify, JSON, typed context). No application policy — no themes, no shortcuts, no business rules.</li> <li> <strong>Registry (<code>vel::ui::</code>)</strong>: 43 baseline widgets in the shadcn idiom — Btn, Card, Tabs, Accordion, Dialog, Sheet, Table, TreeView, Stepper, Image, and so on. Built by composing framework primitives. Third parties can ship their own registries as plain <code>.vel</code> files; the language has cross-file imports as a first-class feature.</li> <li> <strong>Application</strong>: your <code>.vel</code> files and a thin <code>main.cpp</code> shell. Themes, keyboard shortcuts, and routing decisions live here.</li> </ul> <p>Code in a higher tier never reaches into a lower one. The framework never imports an icon set. The runtime never hardcodes a key combo. This isn't religion; it's the only way the language stays composable as third-party registries appear.</p> <h2> Why a DSL — and why compile to C++? </h2> <p>Two reasons.</p> <p>First, <strong>source-token density</strong>. The same UI in JSX vs. Vel:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight jsx"><code><span class="p"><</span><span class="nc">View</span> <span class="na">style</span><span class="p">=</span><span class="si">{</span><span class="p">{</span><span class="na">padding</span><span class="p">:</span> <span class="mi">24</span><span class="p">,</span> <span class="na">gap</span><span class="p">:</span> <span class="mi">12</span><span class="p">,</span> <span class="na">backgroundColor</span><span class="p">:</span> <span class="nx">theme</span><span class="p">.</span><span class="nx">bg0</span><span class="p">,</span> <span class="na">borderRadius</span><span class="p">:</span> <span class="mi">12</span><span class="p">}</span><span class="si">}</span><span class="p">></span> <span class="p"><</span><span class="nc">Text</span> <span class="na">style</span><span class="p">=</span><span class="si">{</span><span class="p">{</span><span class="na">color</span><span class="p">:</span> <span class="nx">theme</span><span class="p">.</span><span class="nx">fg</span><span class="p">,</span> <span class="na">fontWeight</span><span class="p">:</span> <span class="dl">'</span><span class="s1">700</span><span class="dl">'</span><span class="p">}</span><span class="si">}</span><span class="p">></span>Hello<span class="p"></</span><span class="nc">Text</span><span class="p">></span> <span class="p"></</span><span class="nc">View</span><span class="p">></span> </code></pre> </div> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>V p=lg g=md bg=bg0 r=md T "Hello" font=bold </code></pre> </div> <p>That's roughly a 4–6× compression on real components without losing the declarative shape. For LLMs writing UI, that's the difference between fitting a feature in context and not. Vel was designed from day one with agent-authored code as a primary user.</p> <p>Second, <strong>no VM at runtime</strong>. Vel compiles directly to typed C++ that calls into a static <code>libvel</code>. There's no interpreter loop, no JIT, no garbage collector. Layout, paint, and event dispatch are all monomorphic virtual calls on stable widget instances. On idle, the app sits in <code>glfwWaitEventsTimeout</code> and uses ~0 CPU — a global frame-dirty flag short-circuits the entire pipeline until something changes.</p> <h2> The reactive substrate </h2> <p>The keystone primitive is <code>Signal<T></code> — a value plus a listener list. Everything reactive flows from it.</p> <p>In the DSL, <code>@state</code> declarations become typed <code>Signal<T></code> members on the generated component:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>#Counter @count = 0 @doubled = $count 2 // detected as derived → Computed<int> @users: std::vector<User> = await fetchUsers() // → AsyncSignal<...> V g=md T "Count: {$count}, doubled: {$doubled}" font=bold Btn "++" -> click => $count = $count + 1 if $users.loading Spinner else for u in $users.value T "{u.name}" </code></pre> </div> <p>What velc emits, semantically:</p> <ul> <li> <code>Signal<int> count_{0}</code> — plain reactive cell.</li> <li> <code>Computed<int> doubled_{ [this]{ return count_.get() * 2; } }</code> — the codegen walks the init expression's AST, finds <code>$count</code> as a dependency, and binds the computed to it. Any <code>count_.set(...)</code> propagates: count → computed → component → <code>needsRebuild_ = true</code>.</li> <li> <code>AsyncSignal<std::vector<User>> users_</code> — kicked off with <code>std::async(std::launch::async, ...)</code>, polled each tick. Exposes <code>.loading</code> / <code>.ready</code> / <code>.value</code> / <code>.error</code> as method calls in the DSL.</li> <li>The component constructor <code>.listen()</code>s every signal it owns. The next <code>tick()</code> calls <code>rebuild()</code>, re-measures, and re-places before the frame paints. Tree rebuilds are coarse-grained — like React's <code>setState</code>, not Solid's fine-grained reactivity — but the granularity is set per <code>#Component</code>, so it composes cleanly.</li> </ul> <p>Effects (<code>~ $a $b => body</code>) compile to per-dep listeners — declarative side effects without polluting event handlers.</p> <h2> First-class C/C++ interop </h2> <p>The single most important constraint I set: <strong>you must be able to drop any existing C++ codebase into Vel with one line.</strong> No bindings, no schemas, no IDL. The language gives you two primitives:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>use "myorg/db.h" // raw C++ include — verbatim use "ui/card.vel" // cross-file vel import — pulls in components </code></pre> </div> <p>Once a header is in scope, qualified names work in every expression. The lexer learned <code>::</code> so <code>db::fetchUsers()</code>, <code>std::vector<myorg::User></code>, and <code>await myapp::loadAsync()</code> all parse and codegen straight through to the underlying calls. The framework knows nothing about your backend — velc just emits the include and the call site. Your existing C++ links into the binary like any other translation unit.</p> <p>This is the reason Vel exists at all. Every other "new UI language" I've tried makes interop a second-class citizen. Here, the interop is part of the type system from day one — state can be of any C++ type, expressions can call any user namespace, and the DSL's type annotations support templates.</p> <h2> Architecture of the rendering pipeline </h2> <p>The render path is Skia all the way down, but Vel adds a few layout patterns worth noting:</p> <ul> <li> <strong>Constraints model</strong>: identical to Flutter (min/max W/H), one measure pass returns intrinsic size, one place pass writes final rects. A small but important fix in Vel — when the cross axis is unbounded (e.g. inside a scrollable), <code>align=Stretch</code> degrades to <code>Start</code> so children don't get infinite size cascades.</li> <li> <strong>Frame-level damage tracking</strong>: an atomic <code>frameDirty</code> flag, raised by any <code>Widget::markDirty()</code> call, controls whether the next frame runs at all. Animating widgets re-arm the flag from their <code>tick()</code>; static pages don't.</li> <li> <strong>Portal layer for overlays</strong>: tooltips, popovers, dialogs, sheets, menus, and toasts go through an <code>OverlayHost</code> that owns a per-frame portal queue. Widgets nested inside scrolled containers register their panel rect plus the current scroll offset, so the panel paints in screen space regardless of where in the tree it was declared. This solved the classic "popover gets clipped by a Card with <code>clipContent</code>" problem cleanly.</li> <li> <strong>DPR awareness</strong>: the GL context is created at framebuffer resolution, the widget tree lays out in logical points, and the canvas matrix is scaled on each paint. Resize is handled by re-creating the Skia surface against the new framebuffer.</li> </ul> <h2> The registry as a primitive, not a library </h2> <p>The 43-widget baseline ships in <code>vel/ui/</code>, but the registry mechanic isn't reserved for the framework. Any <code>.vel</code> file is a registry artifact. Example:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>// widgets/stat.vel #Stat label:str value:str hint:str="" Card elev=1 V g=xs T $label fg=fgMuted font=uiSm T $value font=bold/display if $hint != "" T $hint fg=fgFaint font=uiSm </code></pre> </div> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>// showcase.vel use "widgets/stat.vel" #Showcase H g=md Stat label="MAU" value="42,103" hint="last 30 days" Stat label="Latency" value="84ms" hint="p99" Stat label="Errors" value="0.02%" hint="↓ 18%" </code></pre> </div> <p>velc resolves the import, parses the imported file to extract the component's param signature, and at the call site emits <code>std::make_unique<vel::gen::Stat>("MAU", "42,103", "last 30 days")</code> — positional constructor args, type-checked statically by the C++ compiler downstream. Third parties can ship registries as bare <code>.vel</code> files via git, vendoring, or eventually a package manifest.</p> <h2> What's working today </h2> <ul> <li>Compiler with lexer, parser (forward-progress-guarded), type checker, codegen, and <code>--watch</code> mode.</li> <li>Reactive substrate: <code>Signal<T></code>, <code>Computed<T></code>, <code>AsyncSignal<T></code>, <code>PersistentSignal<T></code> (auto-syncs to disk), effects, typed <code>ctx<T>(key)</code> Provider substrate.</li> <li>Framework primitives: <code>Router</code> (path matching, history), <code>storage</code> (JSON-backed KV), <code>net</code> (pluggable HTTP shim), <code>io</code> (file ops + watcher), <code>time</code> (debounce / throttle / interval / timeout), <code>validate</code> (form rules), <code>notify</code> (toast bus), <code>json</code> (wraps nlohmann), per-widget cursor states, theme switching with full tree rebuild.</li> <li>Registry: 43 widgets including Table (virtualized, sortable, multi-select), TreeView, Stepper, Image (Skia-decoded with LRU cache), and the full shadcn-style overlay set.</li> <li>DX: agent-readable <code>widgets.json</code> regenerated on every build; cross-file imports; <code>--watch</code> for hot iteration.</li> </ul> <h2> What's next </h2> <p>The big open items are hot reload (file watch is in; <code>dlopen</code> swap of the generated <code>.so</code> is not), a real <code>vel.json</code> package manifest, per-widget damage rectangles (right now damage is frame-level), and a few more registry primitives — Video, SVG, devtools overlay, a syntax-highlighted code editor.</p> <p>If the three-tier story holds — and so far it does — Vel ends up being the smallest source surface area you can use to ship a production native desktop app, with the deepest backend interop story of any framework I'm aware of.</p> <p>I'll keep posting as the registry grows.</p> </article> <article> <h1>From Skia to Lume: writing my own 2D rendering engine for Vel</h1> <p>Sai Chandan Kadarla — Sun, 07 Jun 2026 19:21:02 +0000</p> <p>Vel is about a week old. I started it as a DSL plus framework experiment, and from day one the rendering substrate was Skia. That wasn't an accident. Skia is the most complete 2D rendering API you can drop into a C++ project today. Clean canvas surface, built-in text with system font fallback, image decode, a GPU backend that already works on every desktop OS. If you want a UI framework drawing pixels by the end of the week, Skia is what you reach for.</p> <p>But the plan was always to replace it. Skia is a brilliant CPU-rasterization library bolted to a GPU backend, and as soon as you push it hard, the bolts show. Flutter publicly battled this same class of problems for years before they shipped <a href="https://docs.flutter.dev/perf/impeller" rel="noopener noreferrer">Impeller</a> and finally got rid of the runtime shader-compilation jank that made early Flutter apps stutter. I'd rather not repeat their story. So once the DSL was working and the framework was responding to my changes the way I wanted, I started writing the renderer I actually needed.</p> <p>The new engine is called <strong>Lume</strong>. It lives in <a href="https://github.com/chan27-2/Vel/tree/main/engine" rel="noopener noreferrer"><code>engine/</code></a> of the Vel repo. This post is about why I started with Skia, why I'm replacing it now, and what Lume does differently.</p> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fft1tyln4pkbe5ot91hnq.png" class="article-body-image-wrapper"></a></p> <h2> Why Skia first </h2> <p>Skia gave Vel three things I needed in the first few days of having a framework at all:</p> <ul> <li>A clean <code>SkCanvas</code> API the widget pipeline could draw into without me writing any GPU code.</li> <li>A working text renderer (CoreText on macOS, FreeType elsewhere, all behind the same API) with system font fallback.</li> <li>Image decode plus GPU upload as table-stakes, so Image widgets just worked.</li> </ul> <p>That let me focus on the actual hard problem of the framework, the DSL and the reactive substrate. Layout, signals, hot-reload, event dispatch, the widget registry. The rendering substrate didn't need to be mine yet. Skia was a load-bearing dependency for exactly the amount of time it took the rest of the system to stop being the bottleneck.</p> <h2> Why I'm replacing it now </h2> <p>Once the DSL and framework were in shape, I had a clear view of what the renderer was actually doing for me, and what it was going to cost as the surface area grew. Three things, all well-known to anyone who's tried to ship a Skia-based UI runtime at scale.</p> <p><strong>1. Shader compilation jank.</strong> Skia compiles shaders the first time it sees a new primitive <em>during the frame that wants to draw it</em>. The first time you open a dialog with a blur, you pay 40 to 120 ms while Skia builds the right shader for the GPU. Flutter spent years trying to predict and pre-warm these (the infamous "skp shader cache") and never fully won. The Impeller team's own postmortem describes this as the engine's defining flaw.</p> <p><strong>2. Tessellation on the CPU.</strong> Skia turns rounded rectangles, strokes, and curves into triangle meshes on the CPU, then ships them to the GPU. For one card it's free. For a table of 200 rows with rounded corners and hover highlights, the CPU is doing a lot of work that a fragment shader could do once and for all with <a href="https://iquilezles.org/articles/distfunctions2d/" rel="noopener noreferrer">an analytic SDF</a>.</p> <p><strong>3. The framework didn't own its render path.</strong> This was the real one. Every cross-cutting question I expected to hit later (popovers clipping inside scroll views, text positioning in tight cells, atlas eviction policy, draw order across overlays, HiDPI handling) was eventually going to bottom out in Skia's behavior, and the answer was always going to be "work around it." When you don't control the rendering substrate, every one of those concerns is something you negotiate with a library that doesn't know what your widgets are.</p> <p>I'm not the first person to land here. Flutter, Servo, Bevy's UI work, Slint: every team building a rendering-heavy UI runtime has eventually concluded that owning the engine is the only way to make the rest of the system answer to one design. The cheaper time to do it is before you have a year of code depending on someone else's render path.</p> <h2> What I borrowed from Flutter </h2> <p>Impeller's defining decision is <em>ahead-of-time shader compilation</em>. Every shader the engine could ever need is compiled at build time into Metal or Vulkan IR and bundled with the binary. The "first render is slow" problem goes away because there is no first render. Every shader has already been seen.</p> <p>That insight was the foundation. The other thing I borrowed: keep the pipeline list small. Impeller has on the order of a dozen pipelines, not hundreds. The way you do that is by reducing every primitive you draw to a small set of canonical shapes (rounded rects with optional ring strokes, textured quads, line segments) and varying their behavior through <em>uniforms</em>, not new shaders.</p> <p>Lume's pipeline count today is four:</p> <ol> <li> <strong>Shape</strong>: analytic SDF rounded-rect. Fills, strokes, circles, lines, soft shadows all collapse to this.</li> <li> <strong>Line</strong>: per-segment rotated quad with butt caps for polylines.</li> <li> <strong>Text</strong>: textured quad sampling an R8 glyph atlas.</li> <li> <strong>Image</strong>: textured quad sampling RGBA8 with corner-radius mask.</li> </ol> <p>Every shape in the Vel showcase is one of those four primitives. A <code>roundedFill</code> is the shape pipeline with <code>strokeWidth=0, radius=R</code>. A <code>shadowRect</code> is the same pipeline with <code>blur>0</code>, which switches the fragment shader to a <code>smoothstep</code> falloff instead of the AA clamp. A <code>circleStroke</code> is a shape with <code>radius=w/2</code>. The instance attributes do the heavy lifting; the GPU just rasterizes.</p> <h2> What Lume actually is </h2> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fci36wcawc7jpvz7hfsgj.jpg" class="article-body-image-wrapper"></a></p> <p>The architecture is four layers:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>L1 platform/ → CAMetalLayer attach (macOS). Future: ANativeWindow, HWND, canvas. L2 gpu::Device → Dawn instance + adapter + device + queue (singleton). L2 gpu::Surface → wgpu::Surface bound to the window's native layer. L3 paint/ → DawnPainterImpl: four WGSL pipelines, glyph atlas, per-instance state for shape/line/text/image, submission- order draw segments. L4 Painter API → public surface: fill, roundedFill, stroke, polyline, arc, image, text, pushClip, pushTransform, and so on. </code></pre> </div> <p>The whole stack is <code>engine/include/vel/</code> (public headers) plus <code>engine/src/</code> (about 3,000 lines of implementation). The framework calls into the Painter API and never sees a WebGPU type.</p> <p>Three details that took real effort:</p> <p><strong>The glyph atlas is keyed on physical pixel size.</strong> When you ask for 14 px text on a 2× DPR display, FreeType rasterizes at 28 px. Lume's atlas cache key includes that physical size, so a window dragged to a 1× external monitor doesn't render upsampled-blurry text. It just rasterizes a second 14 px entry and uses that. The dst rect stays in logical pixels; the GPU samples the physical atlas 1:1.</p> <p><strong>Submission-order draw segments.</strong> Originally Lume batched all-shapes, then all-lines, then all-text per frame. This broke the Table widget's sticky header: the header background was drawn before the row text, so row text overdrew the header bg, and rows became visible <em>through</em> the header during scroll. The fix was to track a small <code>DrawCmd</code> list (<code>{kind, firstInstance, count}</code>) in submission order and emit one Draw call per segment. Same-kind cmds fuse. The Table works, and any widget that depends on draw order ("this card needs to be on top of those cards") works for the same reason.</p> <p><strong>Drag capture survives reactive rebuilds.</strong> Vel is signal-driven. When the user drags a Slider, the slider writes to a signal, which triggers a re-render, which replaces the Slider widget instance. The new instance has <code>dragging_=false</code>. The drag dies after one mouse-move event. The fix wasn't in Lume; it was in the framework's <code>EventDispatcher</code>. <code>captureDrag(handler)</code> registers a callable that closes over the slider's geometry plus its <code>onChange</code> (whose own closure captures the long-lived owning component's <code>this</code>). Mouse-move and mouse-up route to the captured handler directly, bypassing the widget tree. Drag continues across any number of rebuilds.</p> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F4pyh3vgzsfer6hmgdnao.png" class="article-body-image-wrapper"></a></p> <h2> The Skia / Impeller / Lume comparison </h2> <p>The dimensions that matter for a 2D UI runtime:</p> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th></th> <th><strong>Skia (Vel v1)</strong></th> <th><strong>Impeller (Flutter)</strong></th> <th><strong>Lume (Vel today)</strong></th> </tr> </thead> <tbody> <tr> <td>Shader compilation</td> <td>JIT, at first-draw time</td> <td>AOT, build-time</td> <td>WGSL precompiled by Dawn at device init</td> </tr> <tr> <td>Shape rendering</td> <td>CPU tessellation → GPU triangles</td> <td>Compute + tessellation hybrid</td> <td>Analytic SDF in the fragment shader</td> </tr> <tr> <td>Pipeline count</td> <td>hundreds (one per primitive + state combo)</td> <td>~12</td> <td>4</td> </tr> <tr> <td>Text</td> <td>CoreText / FreeType per platform</td> <td>Manual rasterizer → MTLTexture atlas</td> <td>FreeType → R8 atlas, OS/2 typo metrics</td> </tr> <tr> <td>Idle frame cost</td> <td>Always paints</td> <td>Always paints</td> <td>~0 (frame-dirty flag short-circuits the whole pipeline)</td> </tr> <tr> <td>HiDPI</td> <td>Surface scaled in canvas</td> <td>Per-pass DPR awareness</td> <td>Atlas keyed on physical px; dst rect in logical px</td> </tr> <tr> <td>Cross-platform reach</td> <td>GL/Vulkan/Metal/D3D11</td> <td>Metal + Vulkan (+ work-in-progress)</td> <td>Dawn handles Metal/Vulkan/D3D12/WebGPU from one WGSL source</td> </tr> <tr> <td>Library code in libvel</td> <td>Skia + image codecs (~25 MB linked)</td> <td>n/a</td> <td>0</td> </tr> <tr> <td> <code>libvel.dylib</code> size (macOS arm64)</td> <td>~30 MB</td> <td>n/a</td> <td><strong>11 MB</strong></td> </tr> <tr> <td>Hot-reload safety</td> <td>Crashes if plugin link drops Skia symbols</td> <td>n/a</td> <td>Plugin links the same <code>libvel.dylib</code>; nothing else to share</td> </tr> </tbody> </table></div> <p>The single most useful number on that table is the bottom one. With Skia gone, the hot-reload plugin no longer needs to think about which graphics symbols it shares with the host. <code>libvel.dylib</code> is the sole boundary. A hot reload re-emits a <code>.vel.cpp</code>, recompiles 200 lines, and <code>dlopen</code>s the new dylib in under a second.</p> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F2relz9oyy5auyx4mjqiu.png" class="article-body-image-wrapper"></a></p> <h2> What Lume doesn't do yet (the honest section) </h2> <p>This is the first usable version of the engine, and I'd be lying if I said it was at parity with Skia for every workload. Three real gaps:</p> <p><strong>Compute-shader Gaussian blur.</strong> Lume's shadow is currently a <code>smoothstep</code> outer falloff applied to the rounded-rect SDF. For small blur radii (4 to 16 px, which covers most UI shadows) it's perceptually identical to a Gaussian. For larger radii it reads as "the rect got bigger and softer at the edges" rather than a true Gaussian. A two-pass separable Gaussian in a compute pipeline is next; for now the cheap approximation is honest about what it is.</p> <p><strong>Complex-script text shaping.</strong> I link HarfBuzz; I don't drive it yet. Latin, Cyrillic, and Greek render correctly. Arabic ligatures, Devanagari conjuncts, vertical text: those are next. The FreeType path is in; the HarfBuzz shaping pass on top of it isn't.</p> <p><strong>The platform surface is macOS-only.</strong> Dawn supports Vulkan and D3D12, so the underlying portability is real. The part missing is the window-to-surface glue. Lume has a <code>SurfaceMac.mm</code> that attaches a <code>CAMetalLayer</code> to a GLFW window's <code>NSView</code>; the Windows and Linux equivalents are file-shaped holes today. CI builds compile against the abstraction, but the surface code is the actual port.</p> <p>The roadmap continues from here: native arcs and dashed strokes via additional pipelines, then HarfBuzz, then compute blur, then a Web target via Dawn plus Emscripten, then Windows and Linux surface layers, then partial-repaint damage rects. Owning the engine means the work is real, but at least it's bounded.</p> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F9jwllrxkgu58qjtf7ubs.png" class="article-body-image-wrapper"></a></p> <h2> The journey is in the git log </h2> <p>The proof that Lume isn't a paper exercise is the diff. The Skia removal was commit <code>0d7a8f4</code>. The reorganized four-tier repo (Lume in <code>engine/</code>, the framework in <code>framework/</code>, the component registry in <code>registry/</code>, and the .vel compiler in <code>velc/</code>) is <code>f5b86af</code>. <code>grep -rE 'Sk[A-Z]|sk_sp' engine framework registry velc</code> returns zero hits. The dependency list in <code>vcpkg.json</code> is six lines now, none of them Skia.<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>dawn : GPU abstraction (Metal/Vulkan/D3D12/WebGPU) freetype : glyph rasterization harfbuzz : complex-script shaping (next) glfw3 : windowing spdlog : logging nlohmann-json : JSON for the framework </code></pre> </div> <p>If you want to read it, the code is at <a href="https://github.com/chan27-2/Vel" rel="noopener noreferrer">github.com/chan27-2/Vel</a>. The README's <a href="https://github.com/chan27-2/Vel#lume--the-rendering-engine" rel="noopener noreferrer">Lume section</a> walks the engine specifically; the <code>engine/</code> tree on <code>main</code> is the smallest version of "a 2D GPU rendering engine you can actually run" I know how to write.</p> <p>The lesson I'd take from this, and I'm saying this because I want to remember it later, is that <em>the rendering substrate is not a library decision</em>. It's an architecture decision. The moment your framework needs to answer cross-cutting questions about hit-testing, atlas eviction, draw order, and HiDPI all at once, you can either keep negotiating with someone else's library or you can write your own. Flutter eventually came to the same conclusion. So did I, just earlier. The work is bigger than it looks. The result is that everything downstream of the renderer stops feeling like it's fighting the renderer.</p> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fpx40qo3dbzg0a30jfplz.png" class="article-body-image-wrapper"></a></p> </article> <article> <h1>What's new in Vel: hot reload, an SDK, and a real editor</h1> <p>Sai Chandan Kadarla — Sat, 06 Jun 2026 20:10:03 +0000</p> <p>When I posted <a href="https://dev.to/blog/building-vel">Building Vel</a> a month ago, the language and runtime worked end-to-end — but everything around them was painful. You had to clone the repo, wait 30–60 minutes for vcpkg to build Skia, restart the binary on every change, and write <code>.vel</code> files in a plain text editor with no help.</p> <p>Here's what shipped to fix that. None of it changed what Vel <em>is</em>. All of it changed what using Vel <em>feels like</em>.</p> <h2> A Flutter-style SDK </h2> <p>The install path is now one line:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>curl <span class="nt">-fsSL</span> https://raw.githubusercontent.com/chan27-2/vel/main/scripts/install-vel.sh | bash <span class="nb">echo</span> <span class="s1">'eval "$(vel shell-init bash)"'</span> <span class="o">>></span> ~/.zshrc vel doctor </code></pre> </div> <p>The script downloads a prebuilt SDK archive for your OS and arch — <code>vel-sdk-<ver>-darwin-arm64.tar.gz</code>, <code>linux-x64.tar.gz</code>, <code>windows-x64.zip</code> — drops it at <code>~/.vel/sdk</code>, and adds <code>vel</code> + <code>velc</code> to your <code>PATH</code>. No Skia compile. No vcpkg bootstrap. First run to working compiler: seconds, not hours.</p> <p>Windows users get the equivalent PowerShell line:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight powershell"><code><span class="n">irm</span><span class="w"> </span><span class="nx">https://raw.githubusercontent.com/chan27-2/vel/main/scripts/install-vel.ps1</span><span class="w"> </span><span class="o">|</span><span class="w"> </span><span class="n">iex</span><span class="w"> </span></code></pre> </div> <p>The model is Flutter's, deliberately:</p> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th>Flutter</th> <th>Vel</th> </tr> </thead> <tbody> <tr> <td><code>~/flutter</code></td> <td><code>~/.vel/sdk</code></td> </tr> <tr> <td> <code>stable</code> / <code>beta</code> channels</td> <td>`vel channel stable\</td> </tr> <tr> <td>{% raw %}<code>flutter upgrade</code> </td> <td><code>vel upgrade</code></td> </tr> <tr> <td><code>flutter doctor</code></td> <td><code>vel doctor</code></td> </tr> </tbody> </table></div> <p>The piece Vel doesn't ship: your final binary still links Skia/GLFW via vcpkg, same as Flutter's platform embedders. The SDK gets you the compiler and the framework — your CMake handles the application link.</p> <h2> Hot reload via dynamic plugins </h2> <p>The biggest architectural change since the introduction post. <code>libvel</code> is now a shared library, and the app shell can <code>dlopen</code> a plugin — your widget tree compiled into its own dylib.</p> <p>The plugin ABI is one symbol:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight cpp"><code><span class="k">extern</span> <span class="s">"C"</span> <span class="n">vel</span><span class="o">::</span><span class="n">Widget</span><span class="o"></span> <span class="nf">vel_create_root</span><span class="p">();</span> </code></pre> </div> <p>The host watches the dylib's mtime every 50ms. When you save a <code>.vel</code> file, a watch loop runs <code>cmake --build build --target showcase_plugin</code> (typically 1–2s for a small edit). The dylib mtime ticks. The host destroys the current root, <code>dlclose</code>s the old handle, <code>dlopen</code>s the new one, and calls <code>vel_create_root()</code> again. The window updates in place.</p> <p>One script wires it all together:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>./scripts/dev-hot.sh </code></pre> </div> <p>That's the dev loop now: edit, save, see the UI change in under two seconds without restarting.</p> <p><strong>What it costs.</strong> Signal state is reset on reload. If you had a form half-filled, those values are gone after the dylib swap — the new root is a fresh tree. This is a deliberate tradeoff: serializing state across an ABI boundary is the kind of feature that ends up dictating every widget's API. For a UI dev loop, "edit structure → see new structure" is what matters; the state comes back when you fill the form once.</p> <p>The other cost: <code>RTLD_LOCAL</code> matters. Plugins are loaded with <code>dlopen(path, RTLD_NOW | RTLD_LOCAL)</code> so symbol tables don't leak across reloads. Without it, the second load picks up stale vtables from the first plugin and crashes on the first virtual call. The teardown order also matters — destroy the old root <em>before</em> <code>dlclose</code>, because the destructors run vtables that live in the plugin's text segment.</p> <h2> A VS Code extension with real diagnostics </h2> <p>Vel has <a href="https://github.com/chan27-2/vel/tree/main/editors/vscode" rel="noopener noreferrer">a VS Code extension</a> now — syntax highlighting, completion, hover, live diagnostics.</p> <p>The interesting part is where the data comes from. Two things were already true about <code>velc</code>:</p> <ol> <li> <code>velc --diagnostics-json file.vel</code> emits structured parse + typecheck errors.</li> <li> <code>velc --docs-json</code> emits the complete widget registry — every widget, every prop, every event, every example — as JSON.</li> </ol> <p>The extension is mostly a thin TypeScript shim over those two outputs. The language server runs <code>velc --diagnostics-json</code> on save and surfaces the errors. Completion and hover read from <code>widgets.json</code> — the <em>same</em> file the docs site is built from. There is one source of truth for "what widgets and props exist," and the compiler owns it.</p> <p>This is the part I'm proudest of. The compiler doing double duty as the registry source means the editor experience never drifts from the language. Add a widget; the editor knows about it on the next sync. Rename a prop; the diagnostics flag every old call site.</p> <h2> A live theme configurator </h2> <p>The framework now ships a <code>ThemeConfig</code> global — accent, radius scale, dark/light — that any widget can flip:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>Btn "Rose" variant=outline -> click => vel::useAccentRose() Btn "Lg" variant=outline -> click => vel::useRadiusLg() Btn "Light" variant=outline -> click => vel::useLightTheme() </code></pre> </div> <p>There are 7 accents (Indigo, Blue, Violet, Rose, Emerald, Amber, Slate), 6 radius scales (None → Full), and dark/light. A single setter call rebuilds the <code>Theme</code> from the config and re-applies it across the tree. The whole UI re-tints in one frame.</p> <p>The detail that took thought: this used to crash. The old path called <code>root->onThemeChanged()</code> synchronously from inside the click dispatch, which rebuilt the entire widget tree — freeing the button that was still executing its own <code>onClick</code> handler. Use-after-free, every time.</p> <p>The fix is deferred rebuild: set a <code>pendingThemeChange_</code> flag and apply the theme at the start of the <em>next</em> frame, after the current event dispatch has unwound. It's now the pattern for any widget action that mutates global state — locale switching will use it next.</p> <h2> EditableText: one widget, two surfaces </h2> <p><code>Input</code> and <code>Textarea</code> shared ~95% of their code — UTF-8 cursor math, blink, key handling, focus sync, char input. They were drifting. Both have been refactored onto a shared <code>EditableText</code> base:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight cpp"><code><span class="k">class</span> <span class="nc">EditableText</span> <span class="o">:</span> <span class="k">public</span> <span class="n">Interactable</span> <span class="p">{</span> <span class="nl">public:</span> <span class="n">std</span><span class="o">::</span><span class="n">string</span> <span class="n">text</span><span class="p">;</span> <span class="n">std</span><span class="o">::</span><span class="n">string</span> <span class="n">placeholder</span><span class="p">;</span> <span class="n">std</span><span class="o">::</span><span class="n">function</span><span class="o"><</span><span class="kt">void</span><span class="p">(</span><span class="k">const</span> <span class="n">std</span><span class="o">::</span><span class="n">string</span><span class="o">&</span><span class="p">)</span><span class="o">></span> <span class="n">onChange</span><span class="p">;</span> <span class="n">std</span><span class="o">::</span><span class="n">function</span><span class="o"><</span><span class="kt">void</span><span class="p">(</span><span class="k">const</span> <span class="n">std</span><span class="o">::</span><span class="n">string</span><span class="o">&</span><span class="p">)</span><span class="o">></span> <span class="n">onSubmit</span><span class="p">;</span> <span class="kt">bool</span> <span class="n">onMouseDown</span><span class="p">(</span><span class="n">Point</span><span class="p">,</span> <span class="n">MouseButton</span><span class="p">)</span> <span class="k">override</span><span class="p">;</span> <span class="c1">// final</span> <span class="kt">bool</span> <span class="n">onKey</span><span class="p">(</span><span class="kt">int</span><span class="p">,</span> <span class="kt">int</span><span class="p">,</span> <span class="kt">bool</span><span class="p">)</span> <span class="k">override</span><span class="p">;</span> <span class="c1">// final</span> <span class="kt">bool</span> <span class="n">onChar</span><span class="p">(</span><span class="kt">unsigned</span> <span class="kt">int</span><span class="p">)</span> <span class="k">override</span><span class="p">;</span> <span class="c1">// final</span> <span class="kt">void</span> <span class="n">tick</span><span class="p">(</span><span class="kt">double</span> <span class="n">now</span><span class="p">)</span> <span class="k">override</span><span class="p">;</span> <span class="c1">// final</span> <span class="nl">protected:</span> <span class="k">virtual</span> <span class="kt">int</span> <span class="n">byteIndexAt</span><span class="p">(</span><span class="n">Point</span> <span class="n">pos</span><span class="p">)</span> <span class="k">const</span><span class="p">;</span> <span class="c1">// override per layout</span> <span class="k">virtual</span> <span class="kt">void</span> <span class="n">onEnterPressed</span><span class="p">();</span> <span class="c1">// Input submits, Textarea inserts \n</span> <span class="p">};</span> </code></pre> </div> <p>Subclasses now only own their rendering and the click-to-cursor mapping. One place to fix backspace-at-position-zero. One place to keep the cursor on a UTF-8 boundary. Adding a <code>PasswordInput</code> or a syntax-highlighted code editor is much smaller now — the base class owns the hard parts.</p> <h2> CI on Linux, macOS, and Windows </h2> <p>Less glamorous, but it matters: GitHub Actions builds Vel on Ubuntu, macOS, and Windows on every push and PR. Each platform builds <code>velc</code>, builds <code>libvel</code>, runs CTest, and runs the showcase smoke test where a display exists.</p> <p>Two things were painful to get right:</p> <ul> <li> <strong>vcpkg caching.</strong> Earlier iterations cached only <code>installed/</code>, which left the cache unable to bootstrap on restore — the <code>.git</code> directory and <code>scripts/</code> were missing. Now the entire <code>vcpkg-root</code> is cached, keyed on the manifest hash. CI cold start dropped from a full Skia build to a tar extract.</li> <li> <strong>Headless runners.</strong> macOS CI has no display; Windows Server runners ship without a usable OpenGL driver, so <code>glfwCreateWindow</code> aborts the showcase. The <code>vel run</code> script now detects <code>MINGW/MSYS/CYGWIN</code> and macOS CI and skips the GUI launch — compile + CTest still cover the toolchain.</li> </ul> <p>Multi-platform CI is the kind of thing you don't notice until it breaks. It took three commits to get right, and I hope to never touch it again.</p> <h2> The showcase, reorganized </h2> <p>A small one but worth flagging: <code>examples/showcase.vel</code> used to be one long scrolling page exercising every primitive. It's now a multi-page demo with a sidebar:</p> <ul> <li>Form Controls</li> <li>Buttons & Cards</li> <li>Data</li> <li>Overlays</li> <li>Theme</li> </ul> <p>Build, then <code>./scripts/vel run ./build/showcase</code> — that's the first thing you see. It's also the integration test that exercises every widget, every prop, and every event.</p> <h2> What's next </h2> <ul> <li> <strong>Per-widget damage rectangles.</strong> Frame-level damage tracking is great for idle apps; per-widget would let animations not repaint the whole screen.</li> <li> <strong><code>vel.json</code> package manifest</strong>, so third-party registries become installable instead of vendored.</li> <li> <strong>A <code>vel new</code> template generator.</strong> The boilerplate to start a Vel project is small but not zero.</li> <li> <strong>More registry primitives</strong> — Video, SVG, a devtools overlay, a syntax-highlighted code editor (which the <code>EditableText</code> refactor now makes practical).</li> </ul> <p>If you tried Vel a month ago and bounced off the install, give it another go. <code>curl -fsSL .../install-vel.sh | bash</code>, run <code>vel doctor</code>, open the showcase. The first ten minutes look very different now.</p> </article> </main></body></html>