Linebender

Linebender in 2026 Q1

2026-04-19T00:00:00+00:00
Apologies for the delay in the update, as the past three months have been a hectic time. Two of the core Linebender team members, myself and Daniel McNab, have moved across the world and started full-time jobs at Canva. Getting onboarded has taken a lot of time and energy, but fortunately, work on Linebender crates remains a core part of our responsibilities. And in the meantime, the community has been pushing forward.</p>
Vello</h2>
We've made big improvements to Vello Hybrid, both in capabilities and in performance.</p>
Several releases, most recently sparse strips 0.0.7</a> (encompassing both Vello CPU and Vello Hybrid) and Vello 0.8.0</a>.</p>
Optimizations include:</p>

Fast paths to bypass full coarse rasterization.</li>
Special case drawing rectangles (as opposed to general Bézier paths)</li>
First cut at glyph caching – more work is needed.</li>
Fixed performance issues with heavy gradient use.</li>
Skipping more unneeded work in layer operations.</li>
Optimizations for opaque full-tile images.</li>
Optimized layer blending for src-over compositing.</li>
Improvements to analytic antialiasing performance.</li> </ul>
Vello Hybrid is currently at roughly beta quality; there are some rough edges still and performance work to be done, but it should be usable.</p>
While we were hoping for a project called Vello API to provide a unified, low level API encompassing both Vello CPU and Vello Hybrid, we ran into more complexity and difficulty than intended. There are two abstraction layers that can be used for a variety of renderers, both Vello and other renderers including Skia.</p>

AnyRender</a>, which is part of Blitz.</li>
imaging</a>, which is part of the forest-rs organization.</li> </ul>
These two crates are fairly similar in scope, but with different emphasis. AnyRender prioritizes ergonomics, in general closely following the traditional canvas API, while imaging is focused on performance and a more complete set of operations.</p>
Glifo</h3>
Until recently, all three manifestations of Vello each had their own copy of code to extract font outlines and render them. For ordinary fonts, this isn't a lot of logic on top of Skrifa. But for color emoji, it's more complicated and involves wiring up a lot more of the imaging model. We've also been finding scope for more operations at the layer between simple rendering and low-level font parsing, including ink skipping for underlines. To handle these functions, we created a crate called "parley_draw" inside the Parley repo, but that wasn't the right name or the right place for it, as these functions aren't really related to text layout. The crate has now been renamed to "Glifo," and has moved into the Vello repo. The new location is to reduce the friction to iterate on the implementation of atlas-based glyph caching.</p>
For a more recent discussion of the scope and goals of Glifo, see the thread #vello > Glifo: A separation of concerns</a>.</p>
In the longer term, we would like to see Glifo become independent of Vello rendering and be adopted by other projects in the ecosystem, but for the time being it should be considered in development.</p>
Parley</h2>
Parley has seen slow but steady improvements in features, including:</p>

parley#536</a> enumerate system fonts on mac using CoreText</li>
parley#540</a> Load fonts from system, and provided paths</li>
parley#551</a> CSS text-indent support</li>
parley#563</a> Implement all possible AccessKit text properties</li> </ul>
Bevy has switched to Parley (Zulip thread</a>).</p>
CuTTY is a fork of Alacritty (a high performance terminal emulator) that has been ported to Vello and Parley (Zulip thread</a>).</p>
Other projects which now use Parley but have not previously been mentioned are:</p>

Gosub engine</a> (browser engine)</li>
drafft-ink</a> (infinite canvas whiteboard)</li>
Takumi</a> (renders HTML/JSX/etc into images)</li> </ul>
It's gratifying to see all this adoption. It seems like recognition that Parley is a viable text layout library for a broad range of applications.</p>
Xilem and Masonry</h2>
Masonry has moved to imaging</a> as an abstraction over the 2D rendering engine (xilem#1696</a>). Previously it had been hardcoded to use Vello classic. Because imaging supports a wide variety of back-ends, Masonry can now operate in a wider variety of environments, including Vello CPU for rendering not requiring a GPU.</p>
Masonry has bunch of new widgets, including Svg, Divider, CollapsePanel, StepInput, RadioButtons, Switch, Clip, Split.</p>
Masonry now has a new layout system (xilem#1560</a>).</p>
Masonry is using `ui-events</code> for more of the integration with system capabilities, including IME (input method editing). This reduces the dependency on winit, and opens the door to deployments not dependent on winit. In the#masonry > Embeddable GUI backend</a> Zulip thread, there is discussion of embedding Masonry in a VST plugin, using baseview instead of winit.</p>`
`We're seeing some cool Xilem apps in the ecosystem, including a port of Runebender to Xilem (Zulip thread</a>). That's especially gratifying to see, as it was the "hero app" for Druid for several years.</p>`
A screenshot of Runebender Xilem. </figcaption> </figure> We've also gotten word of Boomaga-IPP, a refresh of a virtual printer project (Zulip thread</a>).</p> Another interesting app is Scrolled Quran</a> by Muhammad Ragib Hasin.</p> A screenshot of Scrolled Quran. </figcaption> </figure> Fearless SIMD</h2> Fearless SIMD is our SIMD infrastructure library. It provides a solid, portable way to write SIMD code that compiles to Wasm, AArch64, x86, and x86_64.</p> We released fearless_simd 0.4.0</a>, a large step towards the library being generally useful. The major improvement is the use of AVX2 intrinsics on supported platforms. That fulfills the vision of being able to write code that works efficiently in a variety of SIMD vector widths — 128 bit on Neon, and 256 bits on x86.</p> We are starting to see adoption outside Linebender, notably PhastFT</a>, a high performance FFT library. Applications that can benefit from SIMD acceleration should consider fearless_simd, and we are open to feedback on how to improve it further.</p> There will be SIMD discussion at RustWeek, both as part of the Linebender unconference section and hopefully a session in the all-hands. Get in touch if you'd be interested.</p> Related ecosystem projects</h2> There's a lot of interesting activity surrounding Linebender, including projects that use Linebender crates, and adjacent bits of infrastructure.</p> Subduction</h3> It's long been clear there is value in more fully exploiting system compositor capabilities, but it's a hard problem and Linebender projects have so far just been using plain windows and swapchains. I've had a blog post stuck in rough draft for over four years — How to think about the compositor in 2022</a>. Compositor integration is needed for efficient video playback, and is also the best way to stitch native widgets into a GPU-accelerated rendering surface. Bruce Mitchener got tired of waiting and has started the subduction</a> crate, with compelling examples. To learn more, see the Subduction: System compositor integration</a> Zulip thread.</p> A screenshot of the subduction sample app. There are AppKit widgets including text editing, a wgpu surface running shaders, and other layers. </figcaption> </figure> RustWeek</h2> There are two talks from Linebender affiliated people: Nico Burns' talk on Blitz</a>, and Taj Pereira and Alex Jakubowicz' talk on WASM</a>. In addition, Linebender is one of the Unconference</a> tracks. If you are interested in participating in the latter, reach out to me, as I'm the designated community leader.</p> Get Involved</h2> We welcome collaboration on any of our crates. This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p> We host an hour long office hours meeting each week where we discuss what's going on in our projects. See #office hours in Zulip</a> for details. We're also running a separate office hours time dedicated to the renderer collaboration, details also available at that link. Note that office hours are on a break for the remainder of the year. They are expected to continue in January, keep an eye on Zulip for details.</p>



Linebender in December 2025
2026-01-15T00:00:00+00:00
Linebender is an informal open-source organization working on various projects to advance the state of the art in GUI for the Rust programming language</a>.</p>
Vello</h2>
Vello is our vector renderer with three different implementations.
There is the fully GPU compute based Vello, the fully CPU based Vello CPU, and the hybrid GPU/CPU one called Vello Hybrid.
They can draw large 2D scenes with high performance.</p>

vello#1294</a>: Added features to Vello CPU to switch between u8</code> and f32</code> pipelines.</li>
vello#1327</a>: Eliminated overdraw for opaque image fills.</li>
vello#1325</a>: Reduced the memory usage of wide tile commands.</li>
vello#1303</a>: Fixed filter expansion logic for transforms with scale/skew and for clipped layers.</li>
vello#1313</a>: Fixed gradients within a clip layer in Vello Hybrid.</li>
vello#1323</a>: Fixed non-deterministic GPU stroke artifacts.</li>
</ul>



30% performance improvement in this flower's case with the new overdraw handling in Vello CPU / Vello Hybrid.
</figcaption>
</figure>
The work on rendering sparse strip alpha values in GPU compute shaders continued in vello#1293</a>, which added tile intersection checking.
You can follow the progress in #vello > Thoughts on GPU sparse strips</a>.</p>
Masonry and Xilem</h2>
Masonry is the widget system developed by Linebender.
It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>
Xilem is our flagship GUI project, inspired by SwiftUI, which uses Masonry for its widgets.
It lets you build user interfaces declaratively by composing lightweight views together, and will diff them to provide minimal updates to a retained layer.</p>

xilem#1519</a>: Added Canvas</code> widget, for 2d vector drawing.</li>
xilem#1510</a>: Added a new CollectionWidget</code> trait to unify collection widget method naming.</li>
xilem#1527</a>: Added Gap</code> property to Flex</code> and Grid</code>.</li>
xilem#1528</a>: Added alternative text to Image</code> widget.</li>
xilem#1526</a>: Implemented Into<BrushRef></code> for BorderColor</code>.</li>
xilem#1534</a>: Migrated to Kurbo's Axis</code>.</li>
xilem#1488</a>: Renamed map_message</code> to map_message_result</code>.</li>
xilem#1533</a>: Renamed Grid</code> attributes from width</code> / height</code> to row_count</code>, column_count</code>.</li>
xilem#1484</a>: Split Android examples into separate files.</li>
xilem#1503</a>: Split some Xilem code into new a new xilem_masonry</code> package.</li>
xilem#1504</a>: Fixed TextInput</code> placeholder alignment.</li>
xilem#1537</a>: Fixed ScrollBar</code> behavior with large content sizes.</li>
xilem#1540</a>: Improved Flex</code> child constraint accuracy.</li>
xilem#1507</a>: Wrote guidelines for writing Xilem doc examples.</li>
xilem#1544</a>: Documented node non-persistence in accessibility method.</li>
xilem#1545</a>: Now using third person more consistently in docs.</li>
</ul>
Parley</h2>
Parley is a text layout library.
It handles text layout, mostly at the level of line breaking and resolving glyph positions.</p>

parley#436</a>: Migrated text analysis and internationalization to ICU4X.</li>
parley#479</a>, parley#481</a>: Started work on a dedicated glyph rendering crate.</li>
parley#475</a>: Now using ICU4X Script</code> type in fontique</code>.</li>
parley#473</a>: We now bake composite properties data.</li>
parley#487</a>: Export Tag</code> from HarfRust, to allow users to use it directly.</li>
parley#490</a>: Fixed bidi state leaking across layouts.</li>
parley#493</a>: Fixed crash with empty layout.</li>
parley#498</a>: Updated to ui-events</code> 0.2.</li>
</ul>
Kurbo</h2>
Kurbo provides data structures and algorithms for curves and vector paths.</p>

kurbo#534</a>: Optimized RoundedRect::winding</code>.</li>
kurbo#533</a>: Clarified the order of PathEl</code> points.</li>
</ul>
Peniko</h2>
Peniko is a 2D graphics type library which provides a set of generic types that define styles for rendering and composition.</p>

peniko#155</a>: Updated to Kurbo 0.13.</li>
</ul>
Fearless SIMD</h2>
Fearless SIMD is our SIMD infrastructure library.
It provides a solid way for writing SIMD operations portably across Wasm, AArch64, x86, and x86_64.</p>

fearless_simd#141</a>: Added any_true</code>, all_true</code>, any_false</code>, and all_false</code> methods for mask types.</li>
fearless_simd#167</a>: Added precise float-to-integer conversions, which saturate out-of-bounds results and convert NaN</code> to 0</code> on all platforms.</li>
fearless_simd#168</a>: Added Level::is_fallback</code>, which states whether the current SIMD level is the scalar fallback.</li>
fearless_simd#155</a>: Added a vectored shift left operation.</li>
fearless_simd#154</a>: Added documentation for operations and vector types.</li>
fearless_simd#149</a>: Reworked the API.</li>
fearless_simd#158</a>: Renamed madd</code> / msub</code> to mul_add</code> / mul_sub</code> for consistency with std</code>.</li>
fearless_simd#159</a>: Now using native vector types to back SIMD types.</li>
fearless_simd#170</a>: Made Element</code> an associated type on SimdBase</code>.</li>
fearless_simd#180</a>: SimdFrom::simd_from</code> now takes the SIMD token as the first argument instead of the second.</li>
</ul>
Velato</h2>
Velato is our Lottie render library.
The goal is to provide coverage of the large Lottie spec, up to what Vello can render, for use in interactive graphics.</p>
We released Velato 0.8</a> and 0.8.1</a>. 🎉</p>
Bevy Vello</h2>
Bevy Vello is our Bevy integration for Vello.
The goal is to provide support for rendering scenes, text, SVGs, and Lotties in the Bevy game engine.</p>
We released Bevy Vello 0.11</a>, 0.12</a>, and 0.12.1</a>. 🎉</p>

bevy_vello#185</a>: Added support for UiTransform</code> for raw Vello scenes.</li>
bevy_vello#188</a>: Finished adding Bevy 0.17 support.</li>
bevy_vello#191</a>: Renamed SSRenderTarget</code> to VelloRenderTarget</code>.</li>
bevy_vello#195</a>, bevy_vello#196</a>: Fixed AABBs not being correctly calculated.</li>
</ul>
Resvg</h2>
Resvg is our fast, small, portable SVG library.</p>

resvg#980</a>, resvg#981</a>: No longer writing empty <defs /></code>.</li>
resvg#987</a>: Now using checked arithmetic when computing bounding box.</li>
resvg#990</a>: Fixed panicking during pixmap creation.</li>
</ul>
SimpleCSS</h2>
SimpleCSS is a basic CSS 2.1 parser and selector.</p>

simplecss#39</a>: Added support for parsing @font-face</code>.</li>
</ul>
Druid</h2>
Druid is a GUI library which was a predecessor to Xilem, and an ancestor of Masonry.</p>

druid#2410</a>: Updated to Piet 0.7, which is going to be the final Piet version compatible with Druid.</li>
</ul>
Get Involved</h2>
We welcome collaboration on any of our crates.
This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>
We host an hour long office hours meeting each week where we discuss what's going on in our projects.
See #office hours in Zulip</a> for details.
We're also running a separate office hours time dedicated to the renderer collaboration, details also available at that link.</p>


Linebender in November 2025
2025-12-15T00:00:00+00:00
Linebender is an informal open-source organization working on various projects to advance the state of the art in GUI for the Rust programming language</a>.</p>
Vello</h2>
Vello is our GPU vector renderer.
It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>

vello#1203</a>: Introduced a new clipping algorithm for non-layer based clipping.</li>
vello#1286</a>: Added image filters to Vello CPU.</li>
vello#1301</a>: Optimized gradient rendering in Vello CPU.</li>
vello#1237</a>: Added support for non-isolated masks.</li>
vello#1309</a>: Added comprehensive examples to Vello CPU.</li>
</ul>



Vello CPU now has Gaussian Blur, Drop Shadow, and Flood effects.
</figcaption>
</figure>
Masonry and Xilem</h2>
Masonry is the widget system developed by Linebender.
It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>
Xilem is our flagship GUI project, inspired by SwiftUI, which uses Masonry for its widgets.
It lets you build user interfaces declaratively by composing lightweight views together, and will diff them to provide minimal updates to a retained layer.</p>

xilem#1443</a>: Added text size config to Checkbox</code> and TextInput</code>.</li>
xilem#1444</a>: Added support for non-contiguous app state.</li>
xilem#1448</a>: Changed default background and text colors.</li>
xilem#1461</a>: Refactored xilem_core</code> module structure.</li>
xilem#1455</a>: Reworked to_do_mvc</code> example.</li>
xilem#1471</a>: Lifted common View</code> wrappers to xilem_core</code>.</li>
xilem#1470</a>: Renamed MessageContext</code> to MessageCtx</code>.</li>
xilem#1440</a>: Added ResizeObserver</code> for detecting widget size changes.</li>
xilem#1482</a>: Added Passthrough</code> widget for simple widget encapsulation.</li>
xilem#1493</a>, xilem#1494</a>: Added support for efficient child replacement in all widgets.</li>
xilem#1497</a>, xilem#1502</a>: Standardized widget child management methods.</li>
xilem#1492</a>: Added FocusedBorderColor</code> property.</li>
xilem#1505</a>: Now accepting state</code> in Task</code> view.</li>
xilem#1499</a>: Split off WindowView</code> code into MasonryRoot</code>.</li>
xilem#1490</a>: Upgraded to Parley v0.7.0.</li>
</ul>
Eli Heuer has made significant progress in porting our old Druid hero app, Runebender</a>, to Xilem.

Check out the port's repo</a> or follow the progress on Zulip</a>.</p>



Runebender is being ported to Xilem.
</figcaption>
</figure>
Parley</h2>
Parley is a text layout library.
It handles text layout, mostly at the level of line breaking and resolving glyph positions.</p>
We released Parley 0.7</a>. 🎉</p>

parley#449</a>: Optimized line height computation.</li>
parley#367</a>: Added TextWrapMode</code> style.</li>
parley#452</a>: Introduced Unicode data in preparation of migrating to ICU4X.</li>
parley#468</a>: Added word and letter spacing to text layout based on style properties.</li>
parley#467</a>, parley#471</a>: Added fontconfig-dlopen</code> feature to Fontique to control how to load the fontconfig library.</li>
parley#276</a>: Improved trailing whitespace handling.</li>
</ul>
We have also won not just one</a> but two</a> grants from NLnet</a> for additional work on Parley in 2026.
More updates to follow as we finalize the plans.</p>

Kurbo</h2>
Kurbo provides data structures and algorithms for curves and vector paths.</p>
We released Kurbo 0.13</a>. 🎉</p>

kurbo#493</a>: Converted CubicBez::nearest</code> to the poly-cool</code> quintic solver for a nice speedup (3000x for high accuracy!) and better robustness. This just missed the 0.13 release train.</li>
kurbo#521</a>, kurbo#522</a>, kurbo#525</a>, kurbo#524</a>, kurbo#526</a>: Marked a bunch of methods const</code>.</li>
kurbo#527</a>: Derived Hash</code> for Axis</code>.</li>
</ul>
Fearless SIMD</h2>
Fearless SIMD is our SIMD infrastructure library.
It provides a solid way for writing SIMD operations portably across WASM, Aarch64, x86, and x86_64.</p>

fearless_simd#115</a>: Updated x86 codegen to use AVX2 intrinsics.</li>
fearless_simd#123</a>: Widened AVX2's associated types to 256 bits.</li>
fearless_simd#120</a>: Implemented the reinterpret operations without bytemuck</code>.</li>
fearless_simd#130</a>: Implemented core::ops::Not</code> for integer types.</li>
fearless_simd#134</a>: All float-to-integer and integer-to-float conversions are implemented properly on x86. They should now handle all values correctly, including NaN</code>.</li>
fearless_simd#136</a>: The floating-point min_precise</code> and max_precise</code> operations now behave the same way on x86 and WebAssembly as they do on AArch64, returning the non-NaN</code> operand if one operand is NaN</code> and the other is not.
Previously, they returned the second operand if either was NaN</code>.</li>
fearless_simd#140</a>: The load_interleaved</code> and store_interleaved</code> operations now use native intrinsics on x86, instead of using the fallback implementations.</li>
fearless_simd#143</a>: Now using WebAssembly's relaxed SIMD intrinsics if available.</li>
fearless_simd#145</a>: Added the ceil</code> and round_ties_even</code> operations to floating-point vector types.</li>
</ul>
Velato</h2>
Velato is our Lottie render library.
The goal is to provide coverage of the large Lottie spec, up to what Vello can render, for use in interactive graphics.</p>
An assortment of fixes and improvements to Velato's Lottie support to render more complex animations correctly, see the linked PRs for details.</p>

velato#78</a>: Restructured schema to reflect the specification types.</li>
velato#79</a>: Now allowing any skew value.</li>
velato#80</a>: Replaced keyframe</code> with kurbo</code> for tweening.</li>
velato#81</a>: Now tweening with a cubic bezier curve.</li>
velato#82</a>: Fixed flickering issues for certain Lottie configurations.</li>
velato#83</a>: Added support for trimmed paths.</li>
velato#84</a>: Fixed matte layers.</li>
velato#85</a>: Fixed easing handles, by only use the first two components.</li>
</ul>
Bevy Vello</h2>
Bevy Vello is our Bevy integration for Vello.
The goal is to provide support for rendering scenes, text, SVGs, and Lotties in the Bevy game engine.</p>
A lot of work was done to update Bevy Vello for Bevy 0.17.</p>

bevy_vello#180</a>: Updated to Bevy 0.17, plus other dependency updates.</li>
bevy_vello#182</a>: Fixed resize render targets on camera viewport change.</li>
</ul>
Get Involved</h2>
We welcome collaboration on any of our crates.
This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>
We host an hour long office hours meeting each week where we discuss what's going on in our projects.
See #office hours in Zulip</a> for details.
We're also running a separate office hours time dedicated to the renderer collaboration, details also available at that link.
Note that office hours are on a break for the remainder of the year.
They are expected to continue in January, keep an eye on Zulip for details.</p>
If you wish to discuss the Linebender project individually, Daniel is offering "office hours" appointments</a>, which are free to book.
It really helps us to learn what aspects our users care about the most.</p>


Linebender in October 2025
2025-11-13T00:00:00+00:00
Linebender is an informal open-source organization working on various projects to advance the state of the art in GUI for the Rust programming language</a>.</p>
October saw steady progress on our core crates, including a number of releases.</p>
Vello</h2>
Vello is our GPU vector renderer.
It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>
Laurenz Stampl has done his Masters degree at ETH Zurich on high performance CPU rendering of 2D graphics, particularly the techniques used in Vello CPU.
The masters thesis</a> is now published.
It contains up-to-date background on 2D rendering, which is not well represented in the literature, as well as an explanation of the sparse strip method, and benchmarks.</p>




An illustration from Laurenz Stampfl's Masters Thesis, showing the effect of tile size on rendering efficiency.</p>
</figcaption>
</figure>
We released version 0.0.4 of the sparse strips</a> versions of the renderer.
It should be a solid version of Vello CPU</a>, suitable for a wider range of applications where CPU-only rendering is appropriate.
In addition, it is the initial release of Vello Hybrid, a newer approach that uses the GPU to do pixel compositing, but SIMD-accelerated geometry processing on the CPU.</p>
Vello CPU now supports non-isolated blending (vello#1159</a> among others), which is important for HTML5 canvas compatibility.
SVG and COLRv1 emoji, by contrast, which has set priorities for Vello in the past, only support isolated blending.
There are also promising early results for supporting image filters including blurs.</p>
A major development in Vello Hybrid is support for multiple image atlases (vello#1252</a>), which improves performance for image rendering.</p>
Thomas Smith has been making excellent progress on rendering sparse strip alpha values in GPU compute shaders.
This was the original motivation for the sparse strip work.
You can follow the progress in #vello >  Thoughts on GPU sparse strips</a>.</p>
Work on Vello Classic focused on support for web standard compatibility, motivated by Servo integration.
Those features include support for non-premultiplied alpha (vello#1173</a>, vello#1262</a>, vello#1145</a>).
This has been released in Vello v0.6.0</a>, which also upgraded to wgpu v26 for compatibility with Bevy v0.17.</p>
Masonry and Xilem</h2>
Masonry is the widget system developed by Linebender.
It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>
Xilem is our flagship GUI project, inspired by SwiftUI, which uses Masonry for its widgets.
It lets you build user interfaces declaratively by composing lightweight views together, and will diff them to provide minimal updates to a retained layer.</p>
We released version 0.4</a> of both Masonry and Xilem in October.
This release comprises 7 crates, including Xilem Web.
It is the first release to switch over to the new HarfRust library, developed by Google Fonts, for shaping, replacing Swash.</p>
Parley</h2>
Parley is a text layout library.
It handles text layout, mostly at the level of line breaking and resolving glyph positions.</p>
We released version 0.6 of Parley</a>.</p>
Slint has moved from their hand-rolled text implementation to Parley, and released version 1.14</a>.
Linebender is thrilled to have other UI toolkits in the ecosystem adopt our crates.</p>
Much of the development work on Parley is directed toward supporting HTML floats, particularly in Blitz.
parley#421</a> is the main PR tracking this work, and references several other PRs.</p>
There has also been some performance work, which especially impacts larger paragraphs.
This work continues, and we hope to publish quantitative benchmark results (based on the benchmark suite in Cosmic Text) in November.</p>
We're also in the process of migrating to ICU4X for Unicode primitives, replacing our own hand-rolled implementations (parley#436</a>).
This change should improve maintainability.</p>
Fearless SIMD</h2>
Fearless SIMD is our SIMD infrastructure library.
It provides a solid way for writing SIMD operations portably across Wasm, AArch64, x86, and x86_64.</p>
We released Fearless SIMD 0.3</a> in October.
This release contains improvements in integer operations, particularly variable sized shifting, and better native support for fused multiply-add and multiply-subtract.</p>
As development work, we are pursuing a new approach to using intrinsics safely inside #[target_feature]</code> blocks: fearless_simd#108</a>.
Safe SIMD intrinsics</a> were added in Rust 1.87, and we encourage using them when writing architecture-specific code.
An explicit design goal of Fearless SIMD is to allow portable code in cases where the functionality is reasonably common across architectures, but also facilitate "downcasting" to a specific SIMD level when those intrinsics offer higher performance than the portable choice.
For more details on downcasting, see the A plan for SIMD</a> blog post.</p>
Get Involved</h2>
We welcome collaboration on any of our crates.
This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>
We host an hour long office hours meeting each week where we discuss what's going on in our projects.
See #office hours in Zulip</a> for details.
We're also running a separate office hours time dedicated to the renderer collaboration, details also available at that link.</p>
If you wish to discuss the Linebender project individually, Daniel is offering "office hours" appointments</a>, which are free to book.
It really helps us to learn what aspects our users care about the most.</p>


Linebender in September 2025
2025-10-14T00:00:00+00:00
Linebender is an informal open-source organization working on various projects to advance the state of the art in GUI for the Rust programming language</a>.</p>
Vello</h2>
Vello is our GPU vector renderer.
It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>

vello#1183</a>: Support for luminance masks.</li>
vello#1187</a>: Fix flattening tolerance calculation.</li>
vello#1192</a>: Add push_clip_layer</code>, in preparation for removing Mix::Clip</code>.</li>
vello#1224</a>: Update to the latest Peniko main.</li>
vello#1229</a>: Put wgpu's default features behind a wgpu_default</code> feature flag, by Stefan Tammer.</li>
</ul>
We're planning to make a Vello release early in October for compatibility with Bevy v0.17.</p>
Our sparse strip renderers are moving towards maturity.
In September, we have had some improvements in Vello Hybrid's capabilities, and further performance optimisation.
We're planning on making an alpha release of Vello Hybrid in October.</p>

vello#1188</a>: Make the aliasing threshold configurable.</li>
vello#1196</a>: Gradient rendering in Vello Hybrid.</li>
vello#1206</a>: Store data about filled areas in a strip.</li>
vello#1209</a>: Optimise the estimate_num_squads</code> method.</li>
vello#1215</a>: Glyph caching for hinting instances and outline paths.</li>
vello#1221</a>: Unify our sweep gradient handling.</li>
vello#1239</a>: Release Vello CPU v0.0.2</a>. This release was a final release for Peniko v0.4.x compatibility, and we are planning to release Vello CPU v0.1.0 within the first half of October.</li>
</ul>
We're planning to make the beta release of Vello CPU in early October.</p>

Its performance is now extremely competitive - according to our benchmarking</a> is likely the fastest CPU-only renderer in Rust.</p>






Vello Hybrid now fully supports gradient paint types.</p>
</figcaption>
</figure>
Linebender will be represented at the Graphite Community Meetup, details of which can be found in their post</a>.</p>
Linebender Resource Handle</h3>
Peniko's Font</code> (and therefore also Blob</code>) are used as vocabulary types for font resources between crates (such as Vello and Parley).
However, this meant that when Peniko made semver-incompatible releases, those crates could no longer (easily) interoperate.
Additionally, some crates (notably both Parley and Cosmic Text) only depended on Peniko for these interoperability types.</p>
To resolve this, Font</code>, Blob</code>, and WeakBlob</code> in Peniko are now re-exports from a new crate called Linebender Resource Handle</a>.
These types have identical API as in previous releases, but will now be the same type across Peniko versions.
We have made this migration in such a way that these types are also used in the minor releases of Peniko since v0.3.x</code>.
This means that all releases of Parley and Vello from 2025 are entirely cross-compatible.</p>
Additionally, in future releases, Parley will only depend on Linebender Resource Handle instead of Peniko, improving its compilation time for users who use Parley without Vello.</p>
Peniko</h3>
In addition to the migration to Linebender Resource Handle, we have made small but important improvements in Peniko, our crate for shared 2d rendering types.</p>

peniko#115</a>: Add an InterpolationAlphaSpace</code> to gradients. This is helpful for implementing web specs, and should otherwise be ignored by most users.</li>
peniko#123</a>: Rename ImageRenderParams</code> to ImageSampler</code>.</li>
peniko#126</a>: Migrated to Linebender Resource Handle.</li>
peniko#130</a>: Clarify Sweep Gradient Angle rotation and unit. This now is defined to match how Vello was interpreting it.</li>
peniko#139</a>: Better document Mix</code>, Compose</code> and Fill</code>.</li>
peniko#144</a>: Deprecate Mix::Clip</code> and make it no longer the default blend mode.</li>
</ul>
Release v0.4.1</a> is a backport release for the Linebender Resource Handle migration.
We expect to release Peniko v0.5.0 very early in October.</p>
Masonry and Xilem</h2>
Masonry is the widget system developed by Linebender.
It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>
Xilem is our flagship GUI project, inspired by SwiftUI, which uses Masonry for its widgets.
It lets you build user interfaces declaratively by composing lightweight views together, and will diff them to provide minimal updates to a retained layer.</p>

xilem#1383</a>: Add more window options</li>
xilem#1378</a>: Add Slider widget and demo</li>
xilem#1386</a>: Text area improvements</li>
xilem#1388</a>: Simplify multi-window code</li>
xilem#1393</a>: Fix blitting on a transparent window</li>
</ul>
There was some work in Placehero, the Mastodon client which serves as the flagship Xilem application, to support login, but not yet wired up to the UI.</p>

Parley</h2>
Parley is a text layout library.
It handles text layout, mostly at the level of line breaking and resolving glyph positions.</p>

parley#410</a>: Fix the last line of justified text.</li>
parley#414</a>: Remove Kurbo and Peniko dependencies by using Linebender Resource Handle</a>.</li>
parley#418</a>: Upgrade to icu4x 2.0.</li>
parley#421</a> (draft): Enable floats and other advanced layouts.</li>
</ul>
Kurbo</h2>
Kurbo provides data structures and algorithms for curves and vector paths.
We released v0.12</a> at the start of September, primarily including the new stroking work, which improves performance considerably over the previous version.
In addition to the changes in that release, we also performed various optimisations.</p>
Fearless SIMD</h2>
Fearless SIMD is our SIMD infrastructure library.
It provides a solid way for writing SIMD operations portably across WASM, Aarch64, x86, and x86_64.
The improvements we made in September include:</p>

fearless_simd#76</a>: Add SimdBase::witness</code>, allowing access to the Simd</code> implementation from vector types.</li>
fearless_simd#79</a>, fearless_simd#86</a>: Improved bitshifting support.</li>
fearless_simd#80</a>: Implement assignment operators (+=</code>, etc.).</li>
fearless_simd#81</a>: Enable bitcasting between native-width vectors.</li>
fearless_simd#88</a>: Adopt FMA semantics to match std</code>.</li>
fearless_simd#91</a>: Unary integer negation.</li>
fearless_simd#96</a>: Expression-oriented dispatch macro.</li>
</ul>
We look forward to seeing ecosystem use cases develop.</p>
Get Involved</h2>
We welcome collaboration on any of our crates.
This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>
We host an hour long office hours meeting each week where we discuss what's going on in our projects.
See #office hours in Zulip</a> for details.
We're also running a separate office hours time dedicated to the renderer collaboration, details also available at that link.</p>
If you wish to discuss the Linebender project individually, Daniel is offering "office hours" appointments</a>, which are free to book.
It really helps us to learn what aspects our users care about the most.</p>


Linebender in August 2025
2025-09-12T00:00:00+00:00
Linebender is an informal open-source organization working on various projects to advance the state of the art in GUI for the Rust programming language</a>.</p>
Parley</h2>
Parley is a text layout library.
It handles text layout, mostly at the level of line breaking and resolving glyph positions.</p>

parley#400</a>: Migrates Parley to HarfRust</a> for shaping, which is a Rust port of HarfBuzz.</li>
parley#405</a>: Adds a selection of benchmarks.</li>
parley#406</a>, parley#413</a>: Adds internal caching, improving performance significantly.</li>
</ul>
Vello</h2>
Vello is our GPU vector renderer.
It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>

vello#1096</a>: Updated to Wgpu version 26.</li>
vello#1161</a>: Simplifies the API for rendering a wgpu Texture</code> into a Vello Scene</code>.</li>
vello#1169</a>: Increased the Skrifa version to v0.35.0. This was backported as Vello v0.5.1</a>.</li>
vello#1182</a>: Fixed a longstanding issue with our examples, where they would crash if the window was minimised on windows.</li>
</ul>
The biggest updates to the sparse strip renderers this month are the support for blending and caching in Vello Hybrid.
We have also had continued SIMD improvements, including x86 support.</p>

vello#1136</a>: Allows disabling anti-aliasing.</li>
vello#1137</a>, vello#1153</a>: Add support for caching sparse strips.</li>
vello#1149</a>: Support for SSE4.2 and AVX2 SIMD (i.e. on x86 and x86_64).
The benchmark results viewer</a> has been updated to include some x86_64 results.</li>
vello#1177</a>: Move to the new v0.2.0 release of Fearless SIMD.</li>
vello#1155</a>, vello#1178</a>: Add full support for blending to Vello Hybrid.</li>
</ul>




Blending is now supported by Vello Hybrid.</p>
</figcaption>
</figure>
We have additionally been doing further work on Vello's imaging model.
This is partly in service of the integrations of Vello in Graphite</a> and Servo</a>.</p>

color#191</a>, peniko#115</a> (in progress): Add support for interpolating gradients in unpremultiplied space.
This is provided for web compatibility, and shouldn't be used by most users.</li>
peniko#117</a>: Split Image into the sampler and data.</li>
peniko#120</a>, peniko#121</a>: Add Brga</code> and premultiplied image formats.</li>
vello#1183</a> (in progress): Support luminance masks.</li>
</ul>
As of servo#38962</a>, Vello and Vello CPU are the only canvas backends used in Servo.</p>
Fearless SIMD</h3>
Fearless SIMD is our SIMD infrastructure library.
We are developing it in concert with the Vello sparse strips renderers, particularly vello_cpu</code>.
We released Fearless SIMD v0.2.0</a>, the first Fearless SIMD release since 2018.
This included the following changes from August:</p>

fearless_simd#50</a>, fearless_simd#52</a>: Add SSE4.2 support.</li>
fearless_simd#58</a>: Add some initial docs.</li>
fearless_simd#59</a>: Add basic AVX2 support.</li>
fearless_simd#61</a>: Removes f16</code> support to prepare for release.</li>
fearless_simd#69</a>: Fixes a soundness issue with unsafe SIMD functions.</li>
</ul>
With this release, Fearless SIMD is now ready for experimental use outside of Linebender.
It now provides a solid way for writing portable SIMD operations across WASM, Aarch64, x86, and x86_64.
Note however that the library is still in a quite early state - in particular, our documentation is currently only cursory.
Contributions to improve this would be welcome!</p>
Masonry</h2>
Masonry is the widget system developed by Linebender.
It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>

xilem#1207</a>: Make ObjectFit</code>, Linebreaking</code> and SpinnerColor</code> properties.</li>
xilem#1212</a>: Add Widget::Action</code>, which indicates the action type widgets return.</li>
xilem#1226</a>: Refactor tab focus.</li>
xilem#1228</a>: Add placeholder text to text input.</li>
xilem#1250</a>: Move widgets to use a Length</code> type, which represents a number of logical pixels.</li>
xilem#1269</a>: Introduce "focus fallback" mechanism.</li>
xilem#1273</a>: Update to Anymore v1.0.</li>
xilem#1282</a>, many others: Add unit tests for passes.</li>
xilem#1295</a>: Merge TextColor</code> and SpinnerColor</code> into ContentColor</code>.</li>
xilem#1310</a>: Cleans up how the event loop handles being suspended, by Nixon.</li>
xilem#1312</a>: Remove the generic on VirtualScroll.</li>
xilem#1314</a>: Makes the focused indicator for checkboxes larger, by tannal.</li>
xilem#1320</a>: Add NewWindow</code> struct to encapsulate attributes needed to create a window.</li>
xilem#1321</a>: When a new font is loaded, relayout everything.</li>
xilem#1332</a>: Restore base colour customisation.</li>
xilem#1349</a>: Move Masonry's examples from "Masonry Winit" to "Masonry".</li>
xilem#1353</a>: Limit the size of screenshot tests to 8KiB by default.</li>
xilem#1366</a>: Make the Checkbox</code>'s checked state be controlled only by the driver.</li>
xilem#1371</a>: Fix and optimise window resizing and minimising.</li>
</ul>
Xilem</h2>
Xilem is our flagship GUI project, inspired by SwiftUI, which uses Masonry for its widgets.
It lets you build user interfaces declaratively by composing lightweight views together, and will diff them to provide minimal updates to a retained layer.</p>

xilem#1260</a>: Make the virtual scroll implementation much saner.</li>
xilem#1273</a>: Update to Anymore v1.0.</li>
xilem#1363</a>: Fix the declare_property_tuple</code> macro, by Alex Moon.</li>
xilem#1278</a>: Add Prop</code>, which changes how Masonry Properties</code> are applied to more closely match Xilem Web.</li>
xilem#1318</a>: Fix initial font loading in easy cases.</li>
xilem#1333</a>: Add docs about precise capturing, by Nils Martel.</li>
xilem#1348</a>: Add flex_row</code> and flex_col</code> as convenience functions, by Paul Xu.</li>
xilem#1352</a>: Add error handling to virtual cats example, by Nils Martel.</li>
xilem#1357</a>: Fix how the disabled</code> property is handled for text input.</li>
xilem#1364</a>: Remove the app_state</code> parameter from teardown, by Alex Moon.</li>
</ul>
Placehero:</p>

xilem#1323</a>: Use an Action for navigation (rather than directly setting fields on the app state).</li>
xilem#1337</a>: Use virtual scrolling for timelines.</li>
xilem#1370</a>: Show the blurhash based preview of media attachments.</li>
</ul>



Placehero can now load content from anywhere in a user's timeline, and preview images (left).
It can also jump directly to a specific user's timeline by username (right).
Note that full image loading is not yet supported, only the preview based on the blurhash.</p>
</figcaption>
</figure>
Anymore</h2>
On 4 August, we released Anymore v1.0.0</a>.
This is our crate for the fundamental AnyDebug</code> trait, which greatly aids debugging when using dynamically typed values.
Anymore is designed to be used in public APIs; it has a minimal API surface so that it can be extremely stable.
We recommend considering it for use cases where you would otherwise be returning (potentially wrapped) Box<dyn Any></code> values from your libraries.</p>
Kurbo</h2>
Kurbo provides data structures and algorithms for curves and vector paths.
We've been preparing for the 0.12 release:</p>

kurbo#476</a>: Adds an Axis</code> type taken from Masonry.</li>
kurbo#483</a>: Document Kurbo's feature flags.</li>
kurbo#485</a>: Better handle edge cases in cubic_to_quadratic, by Cosimo Lupo.</li>
kurbo#486</a>: Deprecate and replace existing aspect_ratio</code> methods, which used a non-standard definition of aspect ratio.</li>
kurbo#487</a>, kurbo#488</a>, kurbo#489</a>: Remove many long-deprecated items.</li>
kurbo#490</a>: Fix miter join in dashed strokes.</li>
kurbo#493</a> (in progress): Convert CubicBez::nearest</code> to the poly-cool</code> quintic solver.</li>
</ul>
Get Involved</h2>
We welcome collaboration on any of our crates.
This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>
We host an hour long office hours meeting each week where we discuss what's going on in our projects.
See #office hours in Zulip</a> for details.
We're also running a separate office hours time dedicated to the renderer collaboration, details also available at that link.</p>
If you wish to discuss the Linebender project individually, Daniel is offering "office hours" appointments</a>, which are free to book.
It really helps us to learn what aspects our users care about the most.</p>


Linebender in July 2025
2025-08-06T00:00:00+00:00
Linebender is an informal open-source organization working on various projects to advance the state of the art in GUI for the Rust programming language</a>.</p>
Vello</h2>
Vello is our GPU vector renderer.
It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>

vello#785</a>: Fixed strokes with a width of zero being treated as fills.</li>
vello#908</a>: Updated to wgpu version 25.</li>
vello#1093</a>: Disabled runtime checks in shaders using wgpu's new create_shader_module_trusted</code> API, by sagudev.</li>
</ul>
This month's progress on the sparse strips renderers, a collaborative evolution of Vello, has been centered around adding support for NEON and WASM SIMD, as well as making further improvements to multi-threaded rendering.</p>

vello#1064</a>, vello#1086</a>: Image rendering in Vello Hybrid.</li>
vello#1078</a>: Rewrote Vello CPU to be more SIMD-friendly.</li>
vello#1092</a>: Adds support for SIMD flattening.</li>
vello#1103</a>: Optimises alpha coverage calculation in strip rendering.</li>
vello#1105</a>: Ignores paths containing NaN points, giving a warning.</li>
vello#1122</a>: Adds opacity layers to Vello Hybrid.</li>
vello#1134</a>: Reuses FlattenCtx for paths.</li>
kurbo#427</a>: Contains a new stroke expander with significant performance improvements.</li>
</ul>
Our working roadmap</a> outlines the planned timeline for work on the renderers into next year.</p>
An integration of Vello as the backend for Servo's canvas rendering has landed in servo#36821</a> (and also Vello CPU in servo#38282</a>).
You can follow this work at servo#38345</a>.</p>
Benchmarking</h3>
We have performed some benchmarking to understand where Vello CPU's performance lies in the available 2d renderers.
We did this by creating a fork of the Blend2D benchmark harness</a> with the addition of Vello CPU.
We also added Tiny Skia, which is also stewarded by Linebender and is another popular renderer written in Rust.
You can read more about the benchmark methodology on Blend2D's performance page</a>.
We wish to thank the Blend2D team for creating this excellent suite of tests.</p>


The benchmark results page</a> shows the results of running this suite on an Apple M1 Pro.
This shows the results for Blend2D, Agg, Tiny Skia, Vello CPU, Cairo, Skia, and JUCE.
The source for this results page is available on GitHub at https://github.com/LaurenzV/vello_chart</a>.</p>
Some things that should be noted here:</p>

Vello CPU is still under active development, so these are only preliminary results.</li>
We currently do not support x86-64 SIMD, which is why these charts currently only show an ARM machine.
As noted below, we're actively working on x86-64 support.</li>
Tiny Skia's relative performance is documented</a> to be worse on ARM than on x86-64.
We therefore expect the performance gap between Vello CPU and Tiny Skia to be smaller on x86-64.</li>
</ul>
It is clear that vello-cpu</code> has very impressive performance and on track to become the fastest CPU-only renderer in the Rust ecosystem!
Blend2D is still the clear winner in these tests, but vello-cpu</code> takes second place in many of the benchmarks, often beating other mature renderers such as Skia and Cairo.
This is especially the case as the size of the geometry gets larger.
Blend2D and vello-cpu</code> both offer multi-threaded rendering modes (marked by the 2T/4T/8T suffixes, as opposed to ST for single threaded).
Vello CPU's multithreading is especially effective when drawing larger geometries with curves or when using complex paints such as gradients or patterns.</p>
Fearless SIMD</h3>
Fearless SIMD is our SIMD infrastructure library.
We are developing it in concert with the Vello sparse strips renderers, particularly vello_cpu</code>.</p>
To support the significant Vello CPU refactor using SIMD, this month saw the addition of more methods implemented in both Neon and WebAssembly.
Thanks to new contributions from Benjamin Saunders we've started on SSE 4.2 support for x86</code> architectures.</p>

fearless_simd#24</a>, fearless_simd#26</a>, fearless_simd#27</a>: Implement all WASM SIMD methods.</li>
fearless_simd#31</a>: Introduce semantic conversion traits, by Benjamin Saunders.</li>
fearless_simd#42</a> (not yet merged): SSE 4.2 support, by Benjamin Saunders.</li>
</ul>
Masonry</h2>
Masonry is the widget system developed by Linebender.
It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>


xilem#1077</a>: Added the accessibility integration for VirtualScroll.</li>
xilem#1096</a>: Improved the default styles in Masonry, by Marco Melorio.</li>
xilem#1124</a>: Make Checkbox support keyboard interaction, by tannal.</li>
xilem#1130</a>: Rename Textbox</code> to TextInput</code>.</li>
xilem#1163</a>: Make text color controlled through properties.</li>
xilem#1168</a>: Add IndexedStack</code> widget, by Kiran Wells.</li>
xilem#1170</a>, xilem#1178</a>: Use Anymore</a> for all actions.</li>
xilem#1189</a>: Add the active status.</li>
xilem#1200</a>: Simplify both exclusive and immutable raw access to child widgets.</li>
xilem#1212</a>: Add a convenience associated type for the action type generated by each widget.</li>
xilem#1213</a>: Add a post_paint pass, designed for box shadows.</li>
xilem#1215</a>: Create a NewWidget</code> type, which encapsulates the metadata associated with new widgets.</li>
xilem#1223</a>: Add cache to avoid relayouts when constraints haven't changed.</li>
xilem#1237</a>: Add rudimentary clipboard support.</li>
xilem#1239</a>: Add pixel snapping to layout pass.</li>
xilem#1246</a>: Use properties in ProgressBar</code>, by Pufferfish.</li>
xilem#1248</a>: Make all widget associated properties be stored in the same arena.</li>
xilem#1253</a>: Let Masonry's button have any, by Nixon.</li>
</ul>



As of xilem#1096</a> Masonry's default styles have been improved.
This is not a full design system, but is a piecewise improvement.</p>
</figcaption>
</figure>
Xilem</h2>
Xilem is our flagship GUI project, inspired by SwiftUI, which uses Masonry for its widgets.
It lets you build user interfaces declaratively by composing lightweight views together, and will diff them to provide minimal updates to a retained layer.
Our work on Placehero, which is the working name for our Mastodon client example, has inspired several significant architectural improvements in Xilem.</p>

xilem#1117</a>, xilem#1122</a>: Make DynMessage</code> not require Send</code>, and remove the Message</code> generic from View.</li>
xilem#1142</a>: Add an environment system.</li>
xilem#1170</a>: Use Anymore</a> for messages.</li>
xilem#1220</a>, xilem#1256</a>: Use the environment system for avatars in Placehero.</li>
xilem#1257</a>: Avoid per-frame potential  allocations in views with multiple children (i.e. Flex, Grid).</li>
</ul>



For July, we would like to showcase this Chess GUI developed using Xilem by Dr. Salewski.
It can be found in its repository at https://github.com/StefanSalewski/xilem-chess</a>.</p>
</figcaption>
</figure>
Anymore</h2>
You might have noticed mentions of Anymore</a> in both the Xilem and Masonry sections.
This is a new crate which we've created for the AnyDebug</code> trait.
This allows creating dynamically typed values which can be inspected, making debugging downcasting failures much easier.
This crate is designed for stability, so that it can be used for interoperability between projects (without allocation).
We plan to release version 1.0 in early August.</p>
Parley</h2>
Parley is a text layout library.
It handles text layout, mostly at the level of line breaking and resolving glyph positions.</p>

parley#378</a>: Reimplements the fontconfig backend using FFI, improving font matching.</li>
parley#378</a>: Implements shift-click selection extension, by kekelp.</li>
parley#389</a>: Renames variants to more closely match CSS.</li>
parley#395</a>: Adds a method to unregister a loaded font.</li>
</ul>
Kurbo</h2>
We released Kurbo 0.11.3</a>, with some ergonomics and performance improvements, calculation of moments using Green's theorem, and other methods.</p>
As mentioned in the Vello section, the new, faster stroke expansion logic (kurbo#427</a>) has landed in main.
This will be in the upcoming 0.12 release, which is semver-breaking because of changes to the API to reduce memory allocation.</p>
Raph's job change</h2>
Raph Levien has decided to take a voluntary exit offer from Google.
He is very grateful for the opportunity and the support from Google Fonts of Linebender and Rust UI projects.
His last day there will be October 12.
He has a new gig lined up, as well – he plans to join Canva in January, working on rendering and Rust.
That also involves a move to Australia, an exciting new adventure.
Through all the changes, he intends to continue his work on Linebender and Rust UI, though towards the end of the year he will be taking things a bit easy.
The timing of office hours will also need to change, to accommodate the time zone; more updates will be forthcoming.</p>
Get Involved</h2>
We welcome collaboration on any of our crates.
This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>
We host an hour long office hours meeting each week where we discuss what's going on in our projects.
We're also running a separate office hours time dedicated to the renderer collaboration, details also available at that link.
See #office hours in Zulip</a> for details.</p>
If you wish to discuss the Linebender project individually, Daniel is offering "office hours" appointments</a>, which are free to book.
It really helps us to learn what aspects our users care about the most.</p>


Linebender in June 2025
2025-07-09T00:00:00+00:00
Linebender is an informal open-source organization working on various projects to advance the state of the art in GUI for the Rust programming language</a>.</p>
Vello</h2>
Vello is our GPU vector renderer.
It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>

vello#1062</a>: Add smoke test for layer size, by sagudev.</li>
vello#1019</a>: Add Kompari support.</li>
</ul>
This month we continued seeing a massive amount of activity on the sparse strips renderers, a collaborative evolution of Vello.</p>

vello#1023</a>, vello#1029</a>, vello#1041</a> (among others): Optimisations.</li>
vello#1044</a>, vello#1047</a>: Multithreading support.</li>
vello#1053</a>: Add SIMD support (see below).</li>
vello#1060</a>: Make glyph rendering optional in the CPU renderer.</li>
vello#1065</a>, vello#1070</a>: Improved automated testing.</li>
kurbo#427</a> (in review): A new stroke expander with significant performance improvements.</li>
</ul>
This working roadmap</a> outlines the planned timeline for work on the renderers over the next year.</p>
Fearless SIMD</h3>
Much of the recent work on sparse strip rendering has been SIMD-accelerated implementation of the parts running on CPU.
Here, vello#1053</a> is something of the tip of the iceberg.
Our A plan for SIMD</em></a> blog post sketched out our plans to build an abstraction layer to write SIMD code in a safe, portable way, in contrast to the original prototyping which was all done in unsafe core::arch</code> intrinsics.
Since then, there has been rapid progress on the Fearless SIMD</a> project, focusing on SIMD primitives needed to accelerate rendering.
Support for WASM is particularly strong.</p>
The crate has been moving fast and there are no stability guarantees yet, but we are very hopeful that it will be a solid foundation for other projects that can benefit from SIMD acceleration.
We invite projects to start experimenting, and give us feedback.
Discussion is in the #simd channel</a> on the Linebender Zulip.</p>
Masonry</h2>
Masonry is the widget system developed by Linebender.
It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>

xilem#987</a>: Route text events to the root widget if there is no focused widget.</li>
xilem#1038</a>: Support multiple (top-level) desktop windows in Masonry, by Martin Fischer.</li>
xilem#1009</a>: Add properties which only take effect when a widget is hovered/disabled/active.</li>
xilem#1043</a>, xilem#1044</a>: Split out a Masonry Core crate, which can increase parallelism in compilation.</li>
xilem#1048</a>: Split testing into a Masonry Testing crate, allowing certainty that test code isn't inadvertently included in release binaries.</li>
xilem#1053</a>, xilem#1054</a>, xilem#1055</a>, xilem#1056</a>: Add properties to Textbox</code>, Checkbox</code>, Flex</code>, Grid</code>, and SizedBox</code>.</li>
xilem#1086</a>: Validate accessibility tree updates in tests.</li>
</ul>



As of xilem#1038</a> Masonry (and Xilem) support multiple windows.</p>
</figcaption>
</figure>
Xilem</h2>
Xilem is our flagship GUI project, inspired by SwiftUI, which uses Masonry for its widgets.
It lets you build user interfaces declaratively by composing lightweight views together, and will diff them to provide minimal updates to a retained layer.</p>

xilem#608</a>: A ViewSequence</code> called WithoutElements</code>, to allow including side-effects in lists of element children.</li>
xilem#992</a>: Add support for multiple (top-level) desktop windows in Xilem, by Martin Fischer.</li>
xilem#1071</a>: Split Xilem into modules.</li>
xilem#1079</a>, xilem#1085</a>: Provide the app's state to each View</code> during more phases. This will allow many future architecture explorations.</li>
xilem#1078</a>: Allow accessing the channel of new requests for a worker</code> directly.</li>
xilem#1094</a>: Refactor lens</code> into its own view so that the state doesn't need to passed when constructing the view.</li>
xilem#1097</a>: Small example to teach variable length lists, by Nils Martel.</li>
xilem#1102</a>: Add a helper for flex rows, to improve readability of layout code.</li>
</ul>
In June, we started a new initiative for Xilem, a Mastodon client example.
This is being developed alongside Xilem to focus its development.</p>

xilem#1087</a>: Display a single scrollable timeline.</li>
xilem#1089</a>, xilem#1116</a>: Add simple HTML processing to make posts more readable.</li>
xilem#1091</a>: Load and display the avatar of post authors.</li>
xilem#1092</a>: Improve the styling of posts.</li>
xilem#1108</a>: Correctly display boosted posts.</li>
xilem#1114</a>: Allow viewing replies to a post.</li>
</ul>



The Hero app is currently hardcoded to show a subset of Raph's timeline</a>.</p>
</figcaption>
</figure>
Parley</h2>
Parley is a text layout library.
It handles text layout, mostly at the level of line breaking and resolving glyph positions.</p>
In June, we released Parley 0.5.0</a>.
This includes features we talked about in previous months, including restoring Layout: Sync</code>, and improvements to line height handling.</p>

parley#376</a>: An initial version of AttributedText</code>.</li>
parley#381</a>: Select "hard lines" rather than soft lines when triple clicking.</li>
parley#382</a>: Use ui-events-winit in the Vello Editor example.</li>
</ul>
Android View</h2>
Andrdoid View</a> was handed over to the Rust Mobile organisation.</p>
Get Involved</h2>
We welcome collaboration on any of our crates.
This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>
We host an hour long office hours meeting each week where we discuss what's going on in our projects.
We're also running a separate office hours time dedicated to the renderer collaboration, details also available at that link.
See #office hours in Zulip</a> for details.</p>
If you wish to discuss the Linebender project individually, Daniel is offering "office hours" appointments</a>, which are free to book.
It really helps us to learn what aspects our users care about the most.</p>


Linebender in May 2025
2025-06-17T00:00:00+00:00
Linebender is an informal open-source organization working on various projects to advance the state of the art in GUI for the Rust programming language</a>.</p>
RustWeek</h2>
This month saw the RustWeek 2025</a> conference, in Utrecht in the Netherlands.</p>
A lot of things happened!</p>
The talks</h3>
Raph Levien gave a talk titled Faster, easier 2D vector rendering</em>, about Vello's new architecture.
The talk had some nice visuals and a pretty cool demo!</p>

</iframe>
Matt Campbell gave a talk titled AccessKit: reusable UI accessibility</em>, showing off AccessKit and its API and architecture.
The talk also came with a cool demo, showcasing AccessKit's Android integration.</p>
</iframe>
The Anniversary</h3>
RustWeek also saw the release of Rust 1.87</a>, which coincided (to the day!</a>) with the "10 years of Rust" party.</p>
Some members of Linebender were at the party, which was a great experience. See who you can spot on the group photo!</p>

The Unconference</h3>
The Linebender team also went to the UI Unconference, a roundtable where various subjects were broached (accessibility, platform integrations, SVG rendering, etc).</p>
Overall it felt like various project leaders were increasingly interested in pooling resources and using common libraries, but there is still a long way to go on that front.</p>
Masonry</h2>
Masonry is the widget system developed by Linebender.
It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>

xilem#950</a>: Adds support for ui-events</code></a> crate.</li>
xilem#961</a>: Adds default property values and a default theme.</li>
xilem#973</a>: Releases Masonry 0.3.0</a>.</li>
</ul>



xilem#960</a>: Adds new shadow property to buttons.</p>
</figcaption>
</figure>
Xilem</h2>
Xilem is our flagship GUI project, inspired by SwiftUI, which uses Masonry for its widgets.
It lets you build user interfaces declaratively by composing lightweight views together, and will diff them to provide minimal updates to a retained layer.</p>

xilem#964</a>: Handles Masonry properties for more styling options.</li>
xilem#973</a>: Release Xilem 0.3.0</a>.</li>
</ul>
Vello</h2>
Vello is our GPU vector renderer.
It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>

vello#524</a>: Implements pipeline caching, drastically improving Android startup times.</li>
vello#963</a>: Rounds vertical hinting offsets.</li>
vello#966</a>: Releases Vello 0.5.0</a>.</li>
</ul>
This month we continued seeing a massive amount of activity on Vello's sparse strips renderers (see Raph's video above for details), thanks in part to the tireless contributions of Canva developers Alex Gemberg, Taj Pereira and Andrew Jakubowicz, and to the continued work of Laurenz Stampfl as part of his master's project.</p>

vello#937</a>: Adds support for rendering bitmap and COLR glyphs.</li>
vello#948</a>: Adds support for drawing blurred, rounded rectangles.</li>
vello#957</a>: Adds clipping and spatiotemportal allocation to vello_hybrid.</li>
vello#1011</a>: Adds native WebGL backend for vello_hybrid.</li>
vello#1008</a>: Makes vello_common and vello_cpu no_std.</li>
</ul>
This month also saw the first release of vello_cpu</a>!</p>
As the name implies, vello_cpu is a CPU-only renderer for vector graphics using Vello's tech stack.
It's still very experimental (version 0.0.1</a>) and likely to see all sorts of breaking changes, and performance isn't great, but if you want to experiment with it, you can run cargo add vello_cpu</code> in your terminal and start hacking away.</p>
Parley</h2>
Parley is a text layout library.
It handles text layout, mostly at the level of line breaking and resolving glyph positions.</p>

parley#334</a>: Adds editor features required for Android IME.</li>
parley#344</a>: Adds option to quantize vertical layout metrics.</li>
parley#346</a>: Enables Parley/Fontique to compile to wasm with default features enabled, for better discoverability of the wasm target.</li>
parley#349</a>: Releases Parley 0.4.0</a>.</li>
parley#362</a>: Adds absolute and metrics-relative line height styles.</li>
</ul>
Get Involved</h2>
We welcome collaboration on any of our crates.
This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>
We host an hour long office hours meeting each week where we discuss what's going on in our projects.
See #office hours in Zulip</a> for details.
We've also started a separate office hours time dedicated to the renderer collaboration, details also available at that link.</p>

Daniel and Olivier's "office hours" appointments can still be booked by anyone for open-ended discussion of the ecosystem.

See Daniel's schedule here</a>.</li>
See Olivier's schedule here</a>.</li>
</ul>
</li>
</ul>


A plan for SIMD
2025-06-06T00:00:00+00:00
A plan for SIMD</h1>
This document is a followup to the blog post, “Towards fearless SIMD, 7 years later</a>”.
My goal in publishing that was to start a conversation about the best way for Rust to support SIMD programming.
I’ve also done a bit more exploration and had some discussions at RustWeek, and am now prepared to offer a plan.
Ideally, I’d like some level of buy-in from the Rust ecosystem, but in any case it feels Good Enough to proceed with writing a large quantity of SIMD code, which is required for Linebender projects to meet their performance goals.
There's also a companion PR, fearless_simd#3</a>, which moves this proposal forward.</p>
Goals</h2>
The main goals are spelled out in the above-linked blog.
SIMD results in massive speedups for workloads operating on bulk data, especially image processing, media codec, audio.
It is also possible to exploit SIMD for speedups in other applications such as string processing.
The primary goal of this library is to make SIMD programming ergonomic and safe for Rust programmers, making it as easy as possible to achieve near-peak performance across a wide variety of CPUs.
These goals are very similar to those of Highway</a>, a mature and capable SIMD library for C++.</p>
After some more experimentation and reflection, I’d like to explicitly add the following goals:</p>


Lightweight dependency.
The library itself should be quick to build.
It should have no expensive transitive dependencies.
In particular, it should not require proc macro infrastructure.</p>
</li>

Fine-grained levels.
I’ve spent more time looking at CPU stats, and it’s clear there is value in supporting at least SSE 4.2 – in the Firefox hardware survey</a>, AVX-2 support is only 74.2% (previously I was relying on Steam, which has it as 94.66%).</p>
</li>
</ul>
Summary</h2>
We build in the direction of fearless_simd#2</a>, but with a few course corrections.
In particular, instead of manually curating the library and using (declarative) macros to try to reduce repetition and boilerplate, we rely heavily on code generation.
For example, here is the current way to express dispatch:</p>
#[</span>inline</span>(always)]
</span>fn </span>to_srgb_impl</span><S: Simd>(</span>simd</span>: S, </span>rgba</span>: [</span>f32</span>; 4]) -> [</span>f32</span>; </span>4</span>] {
</span>    ...
</span>}
</span>
</span>simd_dispatch!(</span>to_srgb</span>(level, rgba: [</span>f32</span>; </span>4</span>]) -> [</span>f32</span>; </span>4</span>] = to_srgb_impl);
</span></code></pre>
But with an attribute, it could be simplified to something like this (exact syntax may vary):</p>
#[</span>simd_dispatch</span>]
</span>fn </span>to_srgb</span><S: Simd>(</span>level</span>: Level, </span>rgba</span>: [</span>f32</span>; 4]) -> [</span>f32</span>; </span>4</span>] {
</span>    </span>let</span> simd: S = level.</span>get_simd</span>();
</span>    ...
</span>}
</span></code></pre>
While the current fearless_simd#2 prototype implements a handful of types, the goal is to support a full cartesian product of SIMD width 64 to 512, signed and unsigned integer types from 8 to 32 (possibly 64), f32 (possibly f64), and f16 where available (primarily newer ARM chips, though Sapphire Rapids does support it).
For widths greater than native, the library will polyfill with arrays of the native SIMD width.</p>
Note: since that blog post, f16 and Neon f16 instructions are supported in Rust nightly.
It would be possible to polyfill in a hacky way (as is done in fearless_simd#2), but my inclination is to have these depend on Rust support, and similarly for AVX-512.
With luck, these will stabilize soon (and obviously that’s one of our big asks of the Rust project).
[Update: AVX-512 will land in 1.89</a> if things go well; still gathering more info about fp16 but that might also be very soon]</p>
Explicit vs variable width</h2>
One of the big decisions in writing SIMD code is whether to write code with types of explicit width, or to use associated types in a trait which have chip-dependent widths.
The design of pulp</a> strongly favors the latter; the Simd</a> trait has only “natural width” types, and, in particular, there is no implementation of, for example, 256 bit wide operations on Neon.
A key departure from pulp, then, is support for portable explicit width programming.</p>
For Linebender work, I expect 256 bits to be a sweet spot.
Obviously, it’s the natural width of AVX-2, which is a pretty big majority of x86_64 chips.
On Neon, code written for 256 bits will be unrolled somewhat, but there are 32 registers (as opposed to 16 for AVX-2), so register pressure should not be a problem, and high end chips (such as Apple Silicon) have very wide issue, meaning that the number of elements that can be processed in a single clock cycle is similar to other chips with 256 bit vectors but narrower issue.
The main reason to go smaller is when the loop has a high probability of consuming less than 256 bits of input.</p>
In the other direction, the majority of shipping AVX-512 chips are double-pumped, meaning that a 512 bit vector is processed in two clock cycles (see mersenneforum post</a> for more details), each handling 256 bits, so code written to use 512 bits is not significantly faster (I assert this based on some serious experimentation on a Zen 5 laptop).
I also expect this state of affairs to continue for a while; AMD won this design war and Intel is struggling to catch up after flailing for many years.
If and when a significant number of true 512 bit chips ship, that would justify more work to write variants optimized for 512 bits.</p>
For simpler (map-like) workloads performing the same scalar computation for each element separately, I propose adding pulp-like associated natural-width types and operations to the Simd</code> trait.
Following Highway, I think it also makes sense to have some more operations that work in 128 bit blocks.
A motivating use case is f32 color space conversion, where the alpha channel is passed through unmodified; a very reasonable implementation strategy is to do the nonlinear conversion for all channels, then do a blend operation on lane 3 of 128 bit blocks.
(Additional note: in experiments, trying to do this absolutely broke autovectorization).</p>
Light use of macros</h2>
I am quite concerned about the compile time.
A cold build of fearless_simd#2 on an M1 Max is 3.25s.
Considering that building out the full cartesian product of sizes and types will cause about an order of magnitude increase in size, it’s clear that the library has the potential for major impact on compile times.</p>
Using -Z self-profile</code> to investigate, 87.6% of the time is in expand_crate, which I believe is primarily macro expansion [an expert in rustc can confirm or clarify].
This is not hugely surprising, as (following the example of pulp), declarative macros are used very heavily.
A large fraction of that is the safe wrappers for intrinsics (corresponding to core_arch</a> in pulp).</p>
I believe that using codegen to expand out the macros before crate publish time will help greatly with compile times, but this needs to be experimentally validated.
A possible downside is the size of the crate (especially uncompressed), but I expect zlib compression to be very effective given the repetitive, boilerplate nature of the contents.</p>
One use of macros will remain: simd_dispatch</code> as a declarative macro to generate the dispatch wrappers.
Likely the proposed declarative macro improvements</a> could help a lot here.
I’m especially positive about the ability to write attributes as a declarative macro, as that would reduce the stuttering in the existing syntax.</p>
Topics discussed in the blog</h2>
These topics are discussed in the towards fearless SIMD, 7 years later</a> blog, but I'll touch on them here as they are quite important.</p>
Dispatch is done by doing runtime detection once at the beginning of the application, resulting in a Level</code> enum, each variant of which is a zero-sized token type representing CPU capability.
This choice (same as pulp) minimizes cost of runtime detection.</p>
It is possible to write code in a generic SIMD style, and this will work well in some use cases, but we also support downcasting the generic Simd</code> bound to a specific level, at which point that level's chip-specific capabilities are available.</p>
Here's an example of downcasting:</p>
#[</span>inline</span>(always)]
</span>fn </span>copy_alpha</span><S: Simd>(</span>a</span>: f32x4<S>, </span>b</span>: f32x4<S>) -> f32x4<S> {
</span>    #[</span>cfg</span>(target_arch = "</span>x86_64</span>")]
</span>    </span>if let </span>Some(avx2) = a.simd.</span>level</span>().</span>as_avx2</span>() {
</span>        </span>return</span> avx2
</span>            .sse4_1
</span>            ._mm_blend_ps::<8>(a.</span>into</span>(), b.</span>into</span>())
</span>            .</span>simd_into</span>(a.simd);
</span>    }
</span>    #[</span>cfg</span>(target_arch = "</span>aarch64</span>")]
</span>    </span>if let </span>Some(neon) = a.simd.</span>level</span>().</span>as_neon</span>() {
</span>        </span>return</span> neon
</span>            .neon
</span>            .vcopyq_laneq_f32::<3, 3>(a.</span>into</span>(), b.</span>into</span>())
</span>            .</span>simd_into</span>(a.simd);
</span>    }
</span>    </span>let mut</span> result = a;
</span>    result[</span>3</span>] = b[</span>3</span>];
</span>    result
</span>}
</span></code></pre>
In addition, the SIMD types all support core::ops</code>, including implicit splat so it is easy to, say, multiply a vector by a scalar.
This ergonomic feature is present in simdeez</a> and std::simd</a>, but not pulp</a>.</p>
Alternatives considered</h2>
I started prototyping a DSL that compiles into Rust, using proc macro infrastructure.
This would operate in one of two modes, either as a proc macro run at build time, or as codegen to generate .rs files which would typically be checked into a repo, to minimize build time impact.
(I’ll note that this is a particular instance of a much more general need for better staged compilation, which we’re feeling particularly acutely for shader compilation).
At some point I'll post the prototype, as I think it's worthy of being considered if we're going to be doing a full exploration.</p>
While I think this approach has some advantages, it approaches the cost of building a real programming language, with associated needs for tooling etc.
In addition, the proc macro approach really shows seams when it comes to cross-module interactions.</p>
Another possibility is to evolve pulp</a> in the direction we need.
That’s still not out of the question, but the changes proposed are quite extensive, and this could be disruptive to the existing user base, particularly faer</a>.
One goal in publishing this plan is to gather feedback from the pulp community about what they’d like to see happen.</p>
On RVV and SVE</h2>
One topic I didn’t cover in my blog post is RVV and SVE, which are pretty marginal these days but will become more important.
There are some pretty big challenges, and for the most part we’re blocked on Rust support for the intrinsics.
There is work in this direction, including a project goal</a> and an RFC for sized traits</a>.</p>
Taking a longer view, I think there are two modes for “scalable vector” SIMD.
One is to generate asm which operates correctly no matter the SIMD width.
It’s fairly easy to see how to do this for map-like workloads, and I think it’s reasonable to consider this mostly a codegen problem for autovectorization, as opposed to a good use case for explicit SIMD.</p>
The other is to treat scalable vectors as an annoying instruction encoding for SIMD width not known at compile time, and with partial support for operating on fixed-width (128 bit) blocks.
This is essentially the same concept as “Fixed Width Vector Workloads on Variable Width Vectors</a>”.
The entire concept is a bit frustrating because nearly all ARM chips are 128 bits anyway.</p>
See also the paper SIMD Everywhere Optimization from ARM NEON to RISC-V Vector Extensions</a> for an approach to making explicit SIMD code portable to RVV.</p>
Considerations for WASM SIMD</h2>
There’s a Zulip thread</a> on this.
One tricky bit is that WASM doesn’t have runtime feature detection, rather they expect feature detection to be done as part of the negotiation for deciding which WASM blob to serve.
In some ways, this makes sense, as it avoids pretty much all of the difficulties of multiversioning (including potential binary size impact), but it does require attention to build and deployment, especially as the number of cases will grow as relaxed-simd</a> and other extensions ship.
In WASM, since SIMD capabilities are determined at compile time, the Level</code> enum will compile to nothing.
When writing code portable to other targets that require runtime detection, it still makes sense to write code using the Level</code> enum, but on WASM it has zero runtime cost.</p>
Very small SIMD</h2>
In the embedded world, there are a variety of SIMD extensions for small widths.
I believe the standard RVV extension (intended for application class chips) requires a width of at least 128 bits, but there is a Zve64 profile intended for embedded.
Additionally, embedded ARM processors have a SIMD extension called “Helium</a>”, which is still 128 bit but with a smaller register count and more limited instructions.
Given that Linebender is pushing more into no_std</code>, it’s possible we’ll want to support these.
However, I’m not able to find much evidence of Rust support for these.
At this point, probably best to consider it an open question and potential future work.</p>
Discussion</h2>
There’s a discussion thread</a> on Linebender Zulip.
I’ve also opened a thread</a> on Rust Zulip with some gnarly details about stabilizing fp16 on Neon.
There's also a post on /r/rust</a> open for discussion.</p>
I'm posting this now to the Linebender blog to encourage more discussion in the Rust community.
The best place for serious technical discussion is the Zulip thread.
We expect development to continue in the fearless_simd repo</a>.
The library is not yet usable for broad applications, but it might be possible to start implementing SIMD speedups.
We will be implementing speedups in Vello's CPU and hybrid renderers in the coming weeks, and that will guide our priorities.
We are very interested in feedback about which features are missing, or any other friction; these can be filed as issues against the repo, or raised on the Zulip thread.</p>


Linebender in April 2025
2025-05-07T00:00:00+00:00
Linebender is an informal open-source organization working on various projects to advance the state of the art in GUI for the Rust programming language</a>.</p>
RustWeek</h2>
Many members of the Linebender community will be attending the RustWeek 2025</a> conference, in Utrecht next month.
At the time of writing, there are no longer tickets available, although there is a waitlist.
Raph Levien will be giving a talk, titled Faster, easier 2D vector rendering</em></a>.
This will be covering a lot of the sparse strips work discussed in the Vello section</a>.</p>
Matt Campbell will give a talk, titled AccessKit: reusable UI accessibility</em></a>.</p>
We will also be attending the unconference</a>, as part of the "UI, App dev & Browser Summit" group.
We're looking forward to working with other teams in the Rust UI ecosystem there.</p>
Masonry</h2>
Masonry is the widget system developed by Linebender.
It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>

xilem#913</a>, xilem#938</a>: Ongoing work on properties, in preparation for adding more styling options.</li>
xilem#906</a>: Improves Virtual Scrolling to support non-infinite use cases.</li>
xilem#922</a>: Adds support for multiline text input, by alexjg.</li>
xilem#925</a>, xilem#927</a>: Update "line" scrolling to have a more correct speed, by Aaron Muir Hamilton and Alix Bott.</li>
xilem#929</a>: Used trait upcasting to simplify how widgets use Any</code>.</li>
xilem#937</a>: Unifies test screenshots into a single folder, making it clearer which widget they relate to.</li>
</ul>



Masonry now has support for multi-line text inputs.</p>
</figcaption>
</figure>
Xilem</h2>
Xilem is our flagship GUI project, inspired by SwiftUI, which uses Masonry for its widgets.
It lets you build user interfaces declaratively by composing lightweight views together, and will diff them to provide minimal updates to a retained layer.</p>

xilem#920</a>: Slightly improves the handling of messages, using trait upcasting.</li>
xilem#921</a>: Supports Masonry's virtual scrolling in Xilem.</li>
</ul>
Vello</h2>
Vello is our GPU vector renderer.
It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>

vello#886</a>, vello#887</a>: Update the SDL2 example to SDL3.</li>
vello#892</a>: Improved how our snapshot tests are handled in preparation for Kompari integration.</li>
</ul>
Progress on the sparse strips renderers has also been continuing at pace.
The big standout this month is the significant leap in Vello CPU functionality:</p>

vello#923</a>: Blending, compositing, and layers.</li>
vello#893</a>: Linear, radial and sweep gradients.</li>
vello#878</a>: Clipping.</li>
vello#919</a>: Image rendering.</li>
</ul>



An adapted version of Vello CPU's tests, showing support for blending, gradients and image rendering.</p>
</figcaption>
</figure>
The above PRs set the foundation for introducing these features into Vello Hybrid over the coming months.
Another notable released feature is text outline rendering, which allows both renderers to draw text (emoji are not yet supported).</p>

vello#883</a>: Text outline rendering for Vello CPU and Hybrid.</li>
vello#896</a>, vello#897</a>: Make the hinting robust, allowing clearer drawing in more cases.</li>
</ul>
Our working roadmap can be found here</a>.
This roadmap outlines our planned timeline for work on the renderers over the next year.</p>
Parley</h2>
Parley is a text layout library.
It handles text layout, mostly at the level of line breaking and resolving glyph positions.</p>

parley#272</a>: Added Kompari integration for testing into Parley.</li>
parley#315</a>: Implemented properties based on CSS's word-break</code> and overflow-wrap</code>.</li>
parley#342</a>: Fixes a bug in align</code> where the offset wasn't being reset between calls.</li>
</ul>



parley#315</a> added the WordBreak</code> style property, which is set to BreakAll</code> on 'anism' in this screenshot.</p>
</figcaption>
</figure>
Kurbo</h2>
Kurbo</a> provides data structures and algorithms for curves and vector paths.</p>
We released Kurbo 0.11.2</a>, adding the Triangle</code></a> shape, providing more ergomic methods on various shapes, and improving performance.
The following are some highlights of this release.
See the changelog</a> for a full overview.</p>

kurbo#350</a>: Adds the Triangle</code></a> shape.</li>
kurbo#383</a>: Adds an efficient numerical method for approximating ellipse perimeters, originally described by Kummer (1837) and rediscovered by Linderholm and Segal (1995).</li>
kurbo#418</a>: Adds BezPath::with_capacity</code> to allow more efficient allocation if the size of the bezier path is known beforehand.</li>
kurbo#379</a>: Adds some common derives to Stroke</code> and StrokeOpts</code>.</li>
kurbo#384</a>: Implements Div<f64></code> and Mul<f64></code> for Insets</code>.</li>
kurbo#399</a>, kurbo#409</a>: Implement Sum</code> for Vec2</code>, add Vec2::turn_90</code> and Vec2::rotate_scale</code>.</li>
kurbo#412</a>, kurbo#413</a>: Add Size::{min,max}</code> and Size::INFINITY</code>.</li>
kurbo#429</a>: Adds Affine::scale_about</code> and Affine::then_scale_about</code>.</li>
kurbo#390</a>, kurbo#428</a>: Improve performance by reducing the number of operations in Triangle::circumscribed_circle</code> and improving inlining.</li>
</ul>
Multiple improvements to Kurbo are on the roadmap, such as improved stroke expansion in kurbo#427</a>.</p>
Color</h2>
Color</a> provides functionality for representing, converting, parsing, serializing, and manipulating colors in a variety of color spaces.
It closely follows the CSS Color Module Level 4</a> draft spec.</p>
We released Color 0.3.0</a>, featuring the addition of manual chromatic adaptation and absolute color conversions, improved type conversion ergonomics, and more.
This month saw the following changes, all included in the 0.3.0 release.
See the changelog</a> for a full overview.</p>

color#156</a>, color#164</a>, color#165</a>: Add specialized absolute color conversion methods for ProPhoto RGB, ACES2065-1 and ACEScg.
While ColorSpace</code> includes default implementations for absolute color conversions, having these specializations improves computational efficiency.</li>
color#166</a>: Uses faster (and almost-correct</a>) rounding for conversion from double precision floating point to 8-bit integer RGBA formats.
This works around slow x86 rounding behavior.</li>
color#155</a>: Improves ergonomics by implementing From<AlphaColor<_>> for DynamicColor</code> for all color spaces that have a DynamicColor</code> counterpart.</li>
color#157</a>: Removes the deprecated From<Rgba8> for PremulColor<Srgb></code> implementation.</li>
color#145</a>: Fixes handling of powerless/missing components of the HWB color space, which is necessary for correct color interpolation when components are missing.</li>
color#158</a>, color#159</a>: Improve documentation for DynamicColor::interpolate</code> and gradient</code>, including usage examples.</li>
color#149</a>, color#150</a>: Improve constructing constant Missing</code> flags and Missing</code> documentation.</li>
</ul>
Android View</h2>
Android View</a> is a platform integration for Rust code in Android apps.
In April, Android View gained support for text input using the software keyboard, with accessibility support.</p>



Android View now allows many input methods on Android.
This screenshot shows voice to text working in an app using Linebender libraries.
This image has been edited to remove blank areas.</p>
</figcaption>
</figure>
Research and Future Directions</h2>
Linebender has an origin story in being a very research oriented group, looking to break new ground.
While we are focused on shipping code today, we still have an eye on the future and how to be prepared for the new opportunities and technologies that are coming.</p>
Towards the end of April, some members of Linebender started working on ecosystem standardisation of input events, based on the web input events specification.
This work is happening in the UI Events</a> repository.
This is not a Linebender project, but we're watching it with great interest.</p>
We've also started thinking about how to make a renderer abstraction, allowing APIs which can use any of Vello's backends.
The largest difficulty there is related to resources such as images.
For example Vello Hybrid's image type would be a wgpu</code> Texture, whereas Vello CPU should just use a heap-allocated buffer.
We have some existing prototypes, see #vello > Rendering abstraction prototype</a> for example.
This work is likely to now continue after RustWeek.</p>
Get Involved</h2>
We welcome collaboration on any of our crates.
This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>
We host an hour long office hours meeting each week where we discuss what's going on in our projects.
See #office hours in Zulip</a> for details.
We've also started a separate office hours time dedicated to the renderer collaboration, details also available at that link.</p>

Daniel and Olivier's "office hours" appointments can still be booked by anyone for open-ended discussion of the ecosystem.

See Daniel's schedule here</a>.</li>
See Olivier's schedule here</a>.</li>
</ul>
</li>
</ul>


Linebender in March 2025
2025-04-04T00:00:00+00:00
Linebender is an informal open-source organization working on various projects to advance the state of the art in GUI for the Rust programming language</a>.</p>
Masonry</h2>
Masonry is the widget system developed by Linebender.
It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>
We have made a major change to the internal design of Masonry, in xilem#910</a> and xilem#914</a>.
This change splits Masonry into two packages, masonry_core</code> and masonry</code>.
The Masonry crate provides a runner for Masonry core using Winit, and should be used for an integrated app development experience.
Masonry Core contains the implementation of Masonry's widgets and passes, and is designed to be be embedded into existing apps (currently only those which use wgpu).
This should be transparent to existing Masonry users.</p>
We hoped to release a new alpha of Xilem and Masonry to crates.io in March.
However, this was put on hold whilst the Properties experiment we mentioned last month continues:</p>

xilem#873</a>: Implements properties, which is additional data attached to each widget in a uniform way, intended to enable styling.</li>
xilem#892</a>: Uses properties for styling the built-in Button</code> widget.</li>
</ul>



An example of a styled button.</p>
</figcaption>
</figure>
We have also made significant progress outside of these highlighted areas:</p>

xilem#897</a>: Reduced the size of many of our screenshot tests.</li>
xilem#904</a>: Implemented a new algorithm for screenshot testing, which better reflects the aspects of the screenshots we wish to test.
It also implements automatic compression of blessed screenshots using the excellent oxipng</a> library.</li>
xilem#899</a>: Added documentation for lots of items and methods which were missing documentation.</li>
xilem#882</a>: Adds the core of a virtual scrolling widget, a scroll area which loads its child widgets only when they would be visible to the user.
This allows it to be used for extremely large datasets.</li>
</ul>



xilem#882</a> added a virtual scrolling widget. This is the 'Infinite FizzBuzz' example, which also shows how the virtual scrolling can support items with arbitrary heights.</p>
</figcaption>
</figure>
Xilem</h2>
Xilem is our flagship GUI project, inspired by SwiftUI, which uses Masonry for its widgets.
It lets you build user interfaces declaratively by composing lightweight views together, and will diff them to provide minimal updates to a retained layer.</p>

xilem#887</a>: Added a View for the already existing Split widget.</li>
xilem#899</a>: Added some more documentation.</li>
</ul>
Vello</h2>
Vello is our GPU vector renderer.
It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>

vello#841</a>: Fixed incorrect COLR Emoji rendering, which especially impacted users on Windows.
We backported this to create Vello 0.4.1</a>.</li>
vello#817</a>, vello#877</a>: Updates some of our GPU encoding code to not assume that allocators will give over-aligned allocations.</li>
</ul>
We have also renamed the #gpu channel on Zulip to #vello</a>, which better reflects the purpose of the channel.
Progress on the sparse strips renderer has also been continuing at pace:</p>

vello#827</a>: Added some core API types.</li>
vello#828</a>: Imported the implementation of sparse strip production, without rasterisation (Vello Common).</li>
vello#830</a>, vello#832</a>: Added on CPU rasterisation of sparse strips, with integration tests (Vello CPU).</li>
vello#834</a>: Added a tool (Vello Toy) for visualising different stages of the new pipeline.</li>
vello#831</a>: Added the fragment shader based GPU rasteriser for sparse strips (Vello Hybrid).</li>
vello#872</a>: Enable running Vello Hybrid using WebGL2.</li>
vello#867</a>: Benchmarking harness for Vello Common and Vello CPU.</li>
</ul>



Paris-30k rendered using Vello's new hybrid renderer in Firefox on Linux, a browser which does not yet support WebGPU.</p>
</figcaption>
</figure>
The current state of the sparse strip renderers is that they can reliably render scenes where all elements are a solid colour.
Laurenz Stampfl started their master's project working on the CPU-only renderer full-time at the end of March, working towards this roadmap and on a write-up.
The planned ordering of next steps is laid out in our loose roadmap</a>.
You can also follow the progress in #vello > Vello Hybrid</a> and other threads in #vello</a>.
Our weekly renderer office hours specifically aimed at furthering this collaboration are public - for more information about how to join these, follow #office hours</a>.
Work on the renderers is continuing at pace, most recently in these open PRs:</p>

vello#878</a>: Add clipping to Vello CPU.</li>
vello#883</a>: Implements text/glyph rendering.</li>
vello#879</a>: Experimentally runs Vello Hybrid on Android, using the new Android View work, discussed below</a>.</li>
</ul>
Parley</h2>
Parley is a text layout library.
It handles text layout, mostly at the level of line breaking and resolving glyph positions.
The biggest news in March was that an egui community member has opened a PR</a> to replace egui's bespoke text handling with Parley, with buy-in from egui's maintainer.
The author of that change, valadaptive, has been doing fantastic work improving Parley, and has authored many of these changes.</p>

parley#306</a>: Updated register_fonts</code> to take a Blob</code>, which allows more efficient memory usage.</li>
parley#312</a>: Allows customising how registered fonts are matched, useful for implementing web fonts.</li>
parley#296</a>: Makes selected newline characters visible.</li>
parley#316</a>, parley#317</a>: Provides greater access to the internals of PlainEditor</code>.</li>
parley#318</a>: is_done</code> method on BreakLines</code>, for detecting whether linebreaking is finished.</li>
parley#299</a>: Fixed text editing for layouts containing inline boxes.</li>
</ul>



egui#5784</a> significantly improves egui's text rendering by using Parley.</p>
</figcaption>
</figure>
Kurbo</h2>
Kurbo provides data structures and algorithms for curves and vector paths.</p>

kurbo#427</a>: First cut at least-squares offset curves.</li>
kurbo#428</a>: Improve performance of debug builds by more aggressively enabling inlining.</li>
kurbo#429</a>: Add Affine::scale_about</code>. This makes implementing zoom in a user interface more concise.</li>
</ul>
One of the core features in kurbo is expanding a stroked outline to a filled path, which is based on computing accurate approximations to offset curves, a difficult problem in computational geometry.
As tracked in kurbo#317</a>, our existing solution, based on quartic solving, produced good results but was slow.
We've been doing research into much faster techniques based on least-squares error minimization and accelerated Newton techniques, and kurbo#427</a> is the first step in landing that work.
Over the coming months, we plan to refine robustness and performance of the stroke expansion algorithm, and will also explore generalizing it to variable width strokes, an often-requested feature.</p>
Color</h2>
Color</a> provides functionality for representing, converting, parsing, serializing, and manipulating colors in a variety of color spaces.
It closely follows the CSS Color Module Level 4</a> draft spec.</p>

color#144</a>: Improves correctness when interpolating a color with missing components in the ACES 2065-1 colorspace.</li>
</ul>
Kompari</h2>
Kompari</a> is a tool for visual inspection of snapshot tests.</p>

kompari#26</a>: Added support for optimising screenshots using oxipng</code>.</li>
kompari#27</a>: Support detecting unoptimised screenshots (useful for CI).</li>
kompari#34</a>: Added parallel processing of compute intensive tasks.</li>
</ul>
Research and Future Directions</h2>
Linebender has an origin story in being a very research oriented group, looking to break new ground.
While we are focused on shipping code today, we still have an eye on the future and how to be prepared for the new opportunities and technologies that are coming.</p>
Matt Campbell has started work on a new platform integration for Rust code in Android, called Android View</a>.
This is designed to work around several issues from  the activities available when using Winit, which use either NativeActivity</code> or GameActivity</code>.
Both of these do not integrate well with text input, and struggle to interoperate inside existing apps.
This work is in an early stage, and is taking inspiration from several existing solutions to these problems, with a special focus on getting accessibility integration correct.</p>
We have also started work on a Styled Text library, which is designed to allow sharing rich text functionality between Rust libraries.
This is in the very early stages - if you're working on a project which can use this, then input on your requirements will be welcome.
These can be added in #linebender > Styled Text repo</a>.</p>
RustWeek</h2>
Many members of the Linebender community will be attending the RustWeek 2025</a> conference, in Utrecht in May.
At the time of writing, there are still tickets available.
Raph Levien will be giving a talk, titled Faster, easier 2D vector rendering</em></a>.
This will be covering a lot of the sparse strips work discussed in the Vello section</a>.</p>
Matt Campbell will give a talk, titled AccessKit: reusable UI accessibility</em></a>.</p>
Get Involved</h2>
We welcome collaboration on any of our crates.
This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>
We host an hour long office hours meeting each week where we discuss what's going on in our projects.
See #office hours in Zulip</a> for details.
We've also started a separate office hours time dedicated to the renderer collaboration, details also available at that link.</p>

Daniel and Olivier's "office hours" appointments can still be booked by anyone for open-ended discussion of the ecosystem.

See Daniel's schedule here</a>.</li>
See Olivier's schedule here</a>.</li>
</ul>
</li>
</ul>


Towards fearless SIMD, 7 years later
2025-03-29T00:00:00+00:00
Seven years ago I wrote a blog post Towards fearless SIMD</a>, outlining a vision for Rust as a compelling language for writing fast SIMD programs.
Where are we now?</p>
Unfortunately, the present-day experience of writing SIMD in Rust is still pretty rough, though there has been progress, and there are promising efforts underway.
As in the previous post, this post will outline a possible vision.</p>
Up to now, Linebender projects have not used SIMD, but that is changing.
As we work on CPU/GPU hybrid rendering techniques, it's clear that we need SIMD to get maximal performance of the CPU side.
We also see opportunities in faster color conversion and accelerated 2D geometry primitives.</p>
This blog post is also a companion to a podcast</a> I recorded recently with André Popovitch.
That podcast is a good introduction to SIMD concepts, while this blog post focuses more on future directions.</p>
A simple example</h2>
As a running example, we'll compute a sigmoid</a> function for a vector of 4 values.
The scalar version is as follows:</p>
fn </span>sigmoid</span>(</span>x</span>: [</span>f32</span>; 4]) -> [</span>f32</span>; </span>4</span>] {
</span>    x.</span>map</span>(|</span>y</span>| y / (</span>1.0 </span>+ y * y).</span>sqrt</span>())
</span>}
</span></code></pre>
This particular simple code autovectorizes nicely (Godbolt link</a>), but more complex examples often fail to autovectorize, often because of subtle differences in floating point semantics.
(Editorial note: a previous version of this post didn't autovectorize (Godbolt</a>) because optimization level was set at -O</code>, which is less aggressive than -C opt-level=3</code>, the latter of which is the default for release builds)</p>
Safety</h2>
One of the biggest problems with writing SIMD in Rust is that all exposed SIMD intrinsics are marked as unsafe</code>, even in cases where they can be used safely.
The reason is that support for SIMD features varies widely, and executing a SIMD instruction on a CPU that does not support it is undefined behavior – the chip can crash, ignore the instruction, or do something unexpected.
To be used safely, there must be some other mechanism to establish that the CPU does support the feature.</p>
Here's the running example in hand-written intrinsic code, showing the need to write unsafe</code> to access SIMD intrinsics at all:</p>
#[</span>cfg</span>(target_arch = "</span>aarch64</span>")]
</span>fn </span>sigmoid_neon</span>(</span>x</span>: [</span>f32</span>; 4]) -> [</span>f32</span>; </span>4</span>] {
</span>    </span>use </span>core::arch::aarch64::*;
</span>    </span>unsafe </span>{
</span>        </span>let</span> x_simd = core::mem::transmute(x);
</span>        </span>let</span> x_squared = </span>vmulq_f32</span>(x_simd, x_simd);
</span>        </span>let</span> ones = </span>vdupq_n_f32</span>(</span>1.0</span>);
</span>        </span>let</span> sum = </span>vaddq_f32</span>(ones, x_squared);
</span>        </span>let</span> sqrt = </span>vsqrtq_f32</span>(sum);
</span>        </span>let</span> ratio = </span>vdivq_f32</span>(x_simd, sqrt);
</span>        core::mem::transmute(ratio)
</span>    }
</span>}
</span>
</span>#[</span>cfg</span>(target_arch = "</span>x86_64</span>")]
</span>fn </span>sigmoid_sse2</span>(</span>x</span>: [</span>f32</span>; 4]) -> [</span>f32</span>; </span>4</span>] {
</span>    </span>use </span>core::arch::x86_64::*;
</span>    </span>unsafe </span>{
</span>        </span>let</span> x_simd = core::mem::transmute(x);
</span>        </span>let</span> x_squared = </span>_mm_mul_ps</span>(x_simd, x_simd);
</span>        </span>let</span> ones = </span>_mm_set1_ps</span>(</span>1.0</span>);
</span>        </span>let</span> sum = </span>_mm_add_ps</span>(ones, x_squared);
</span>        </span>let</span> sqrt = </span>_mm_sqrt_ps</span>(sum);
</span>        </span>let</span> ratio = </span>_mm_div_ps</span>(x_simd, sqrt);
</span>        core::mem::transmute(ratio)
</span>    }
</span>}
</span></code></pre>
This is quite a simplified example.
For one, the SIMD width is fixed at 4 lanes (128 bits).
Most likely, in practice you'd iterate over a larger slice, taking chunks equal to the natural SIMD width.</p>
Multiversioning</h2>
A central problem important for SIMD is multiversioning and runtime dispatch.
In some cases, you know the exact CPU target, for example when compiling a binary you'll run only on your machine (in which case target-cpu=native</code> is appropriate).
But when distributing software more widely, there may be a range of capabilities.
For highest performance, it's necessary to compile multiple versions of the code, and do runtime detection to dispatch to the best SIMD code the hardware can run.
This problem was expressed in the original fearless SIMD blog post, and there hasn't been significant advance at the Rust language level since then.</p>
In the C++ world, the Highway</a> library provides excellent SIMD support for a very wide range of targets, and also solves the multiversioning problem.
Among other uses are the codecs for the JPEG-XL image format.
Such codecs are an ideal use case for SIMD programming in general, and shipping them in a browser requires a good solution to multiversioning.
Highway has a really good explanation of their approach to multiversioning</a>.
It will be useful to study it carefully to see how they've solved various problems.
And a concise way of saying what I'd like to see is "Highway for Rust."</p>
One possible approach is a crate called multiversion</a>, which uses macros to replicate the code for multiple versions.
A more recent macro-based approach is rust-target-feature-dispatch</a>.
It is generally a similar approach to multiversion, and the specific differences are set out in that crate's README</a>.</p>
Another approach, as I believe first advocated in my 2018 blog post, is to write functions polymorphic on a zero-sized type representing the SIMD capabilities, then rely on monomorphization to create the various versions.
One motivation for this approach is to encode safety in Rust's type system.
Having the zero-sized token is proof of the underlying CPU having a certain level of SIMD capability, so calling those intrinsics is safe.
A major library that uses this approach is pulp</a>, which also powers the faer</a> linear algebra library.</p>
I started putting together a pulp version of the running example, but ran into the immediate problem that it lacks a sqrt</code> intrinsic (this would be easy enough to add, however).
It also works a bit differently, in that it only supports vectors of the natural width, not ones of a fixed width.
For general linear algebra, that's fine, but for some other applications it adds friction, for example colors with alpha are naturally chunks of 4 scalars.
To see an example of pulp code, as well as some discussion, see this Zulip thread</a>.</p>
In fearless_simd#2</a> I propose a prototype of reasonably-ergonomic SIMD multiversioning.
Like the original fearless_simd prototype, vector data types are polymorphic on SIMD level.
The new prototype goes beyond that in several important ways.
For one, arithmetic traits in std::ops are implemented for vector types, so it's possible to add two vectors together, multiply vectors by scalars, etc.</p>
Here's what the running example looks like in that prototype:</p>
#[</span>inline</span>(always)]
</span>fn </span>sigmoid_impl</span><S: Simd>(</span>simd</span>: S, </span>x</span>: [</span>f32</span>; 4]) -> [</span>f32</span>; </span>4</span>] {
</span>    </span>let</span> x_simd: f32x4<S> = x.</span>simd_into</span>(simd);
</span>    (x_simd / (</span>1.0 </span>+ x_simd * x_simd).</span>sqrt</span>()).</span>into</span>()
</span>}
</span>
</span>simd_dispatch!(</span>sigmoid</span>(level, rgba: [</span>f32</span>; </span>4</span>]) -> [</span>f32</span>; </span>4</span>] = sigmoid_impl);
</span></code></pre>
An advantage of the fearless_simd#2 prototype over pulp is a feature for downcasting based on SIMD level, so it's possible to write different code optimized for different chips.
See the srgb example</a> in that pull request for more detail.
Though there are clear advantages, at this point I'm not sure whether this is the direction to go.
It would be a lot of work to build out all the needed types and operations, with potentially a large amount of repetitive boilerplate code in the library, which in turn may cause issues with compile time.
Another possible direction is a smarter, compiler-like proc macro which synthesizes the SIMD intrinsics as needed based on the types and operations in the source program.</p>
One additional consideration for Rust is that the implementation of runtime feature detection is slower than it should be</a>.
Thus, feature detection and dispatch shouldn't be done at every function call.
A good working solution is to do feature detection once, at the start of the program, then pass that token down through function calls.
It's workable but definitely an ergonomic paper cut.</p>
FP16 and AVX-512</h2>
A general trend in parallel computation, really fueled by AI workloads, is smaller scalars with higher throughputs.
While not yet common on x86_64, the FP16 extension is supported on all Apple Silicon desktop CPUs and most recent high-ish end ARM-based phones.
Since Neon is only 128 bits wide, having 8 lanes is welcome.
I find the f16 format to be especially useful for pixel values, as it can encode color values with more than enough precision to avoid visual artifacts (8 bits is not quite enough, though it is good enough for some applications, as long as you're not trying to do HDR).</p>
Native Rust support for the f16</code> type has not yet landed (tracked in rust#125440</a>), which makes use of this scalar size harder.
However, there is some support in the half</a> library, and also the fearless_simd#2</a> prototype exports a number of FP16 Neon instructions through inline assembly.
When true f16 support lands, it will be possible to switch over to intrinsics, which will have better optimization and ergonomics (for example, the same method will splat constants converted to f16</code> at compile time and f32</code> variables to be converted at runtime).</p>
AVX-512 is a somewhat controversial SIMD capability.
It first appeared in the ill-fated Larrabee project, which shipped in limited numbers as the Xeon Phi starting in 2010, and has since appeared in scattered Intel CPUs, but with compromises.
In particular, sprinkling even a small amount of AVX-512 code into a program could result in downclocking, reducing performance for all workloads (see Stack Overflow thread on throttling</a> for more details).
These days, the most likely way to get a CPU with AVX-512 is an AMD Zen 4 or Zen 5; it is on their strength that AVX-512 makes up about 16% of computers in the Steam hardware survey.</p>
The increased width is not the main reason to be enthusiastic about AVX-512.
Indeed, on Zen 4 and most Zen 5 chips, the datapath is 256 bits so full 512 bit instructions are "double pumped." The most exciting aspect is predication based on masks, a common implementation technique on GPUs.
In particular, memory load and store operations are safe when the mask bit is zero, which is especially helpful for using SIMD efficiently on strings.
Without predication, a common technique is to write two loops, the first handling only even multiples of the SIMD width, and a second, usually written as scalars, to handle the odd-size "tail".
There are lots of problems with this - code bloat, worse branch prediction, inability to exploit SIMD for chunks slightly less than the natural SIMD width (which gets worse as SIMD grows wider), and risks that the two loops don't have exactly the same behavior.</p>
Going forward, Intel has proposed AVX10, and will hopefully ship AVX 10.2 chips in the next few years.
This extension has pretty much all of the features of AVX-512, with some cleanups and new features (until recently, AVX10 was defined has having a 256 bit base width and optionally 512, but 512 is now the baseline).
In addition, AVX10.2 will include 16-bit floats (currently available only in the Sapphire Rapids high-end server and workstation chips).</p>
About std::simd</h2>
The "portable SIMD" work has been going on for many years and currently has a home as the nightly std::simd</a>.
While I think it will be very useful in many applications, I am not personally very excited about it for my applications.
For one, because it emphasizes portability, it encourages a "lowest common denominator" approach, while I believe that for certain use cases it will be important to tune algorithms to best use the specific quirks of the different SIMD implementations.
For two, std::simd does not itself solve the multiversion problem.
From my perspective, it's probably best to consider it as a souped-up version of autovectorization.</p>
Language evolution</h2>
Rust's out of the box support for SIMD is still quite rough, especially the need to use unsafe</code> extensively.
While some of the gap can be filled with libraries, arguably it should be a goal of the language itself to support safe SIMD code.
There is progress in this direction.</p>
First, the original version of target_feature</code> requires unsafe</code> to call into any</em> function annotated with #[target_feature]</code>.
A proposal to relax that so that functions already under a target_feature gate can call safely call into another function with the same gate is called "target_feature 1.1</a>" and is scheduled to ship in 1.86.
Closely related, once inside the suitable target_feature gate, the majority of SIMD intrinsics (broadly, those that don't do memory access through pointers) should be considered safe by the compiler, and that feature (safe intrinsics in core::arch) is also in flight.</p>
There's more that can be done to help the Rust compiler recognize when SIMD use is safe, in particular to allow target_features when a concrete witness to the SIMD level is passed in as a function argument.
The "struct target_features" proposal (RFC 3525</a>) enables target_feature in such cases, and is one of the proposals considered in the proposed Rust project goal Nightly support for ergonomic SIMD multiversioning</a>.</p>
In general, improving Rust SIMD support will require both libraries and support in the Rust language.
Different approaches at the library level may indicate different language features to best support them.</p>
Looking forward</h2>
My main goal in putting these prototypes forward, as well as writing these blog posts, is to spark conversation on how best to support SIMD programming in Rust.
If done well, it is a great opportunity for the language, and fits in with its focus on performance and portability.</p>
As we build out the Vello hybrid CPU/GPU renderer</a>, performance of the CPU components will rely heavily on SIMD, so we need to invest in writing a lot of SIMD code.
The most conservative approach would be hand-writing unsafe intrinsics-based code for all targets, but that's a lot of work and the use of unsafe is unappealing.
I'd love for the Rust ecosystem can come together and build good infrastructure, competitive with Highway.
For now, I think it's time to carefully consider the design space and try to come to consensus on what that should look like.</p>



Linebender in February 2025
2025-03-20T00:00:00+00:00
Linebender is an informal open-source organization working on various projects to advance the state of the art in GUI for the Rust programming language</a>.</p>
Xilem</h2>
Xilem is our flagship GUI project, inspired by SwiftUI.
It lets you build user interfaces declaratively by composing lightweight views together, and will diff them to provide minimal updates to a retained layer.
February was a slow month for Xilem specific changes, although many changes further down the stack will be relevant to Xilem users.</p>

xilem#861</a>: makes a method on Pod</code> public to make creating widgets easier, by Evgeny.</li>
</ul>
Masonry</h2>
Masonry is the widget system used by Xilem.
It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>

xilem#872</a>: Exported the scale factor for limited use cases (such as single-pixel lines).</li>
</ul>
There is some important work upcoming:</p>

xilem#873</a>: Olivier started to develop his "arbitrary properties" feature, which is intended for styling.</li>
xilem#875</a>: Adds an image widget containing arbitrary vector graphics content, by Richard Dodd.</li>
</ul>
As Parley has now been released to crates.io (discussed later in this update), we're hoping to release a new alpha of Xilem and Masonry to crates.io in March.</p>
Vello</h2>
Vello is our GPU vector renderer.
It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>

vello#803</a>: Removed the render_to_surface</code> API, as wgpu</code>'s new TextureBlitter</code></a> utility makes it unnecessary.</li>
vello#832</a> (in review): Jared Moulton added support for font embolden to our text handling.</li>
</ul>
Last month we mentioned a research exploration into a CPU/GPU hybrid 2D rendering mode.
This hybrid mode works well on downlevel GPUs without strong support for compute shaders, and is also more memory efficient.
There has been a lot of interest from the community, and we are now moving forward with building out this rendering mode in Vello.
We are very excited that Alex Gemberg and Taj Pereira, two engineers from Canva, are joining the collaboration on this renderer.</p>
In February, Raph opened vello#818</a>, which provided the first implementation of this hybrid pipeline.
We are planning to refactor this to share most of its code with an ongoing CPU-only implementation, which we expect to be extremely competitive in performance.
To that aim, we have landed vello#826</a>, which provided the repository-layout scaffolding, in the sparse_strips</code> folder.
This initial PR is just a stub, but we are planning on filling these crates out imminently, allowing collaborative work on both pipelines (hybrid and CPU-only).
You can follow the progress in #vello > Vello Hybrid</a> and other threads in #vello</a>.</p>
Parley</h2>
Parley is a text layout library.
It handles text layout, mostly at the level of line breaking and resolving glyph positions.</p>
We released Parley and Fontique 0.3.0</a> to crates.io.
These contain many of the features we have discussed over the previous months, including significant improvements to PlainEditor</code>.</p>
Resvg</h2>
We released Resvg 0.45.0</a> in February.
This is the first release under the stewardship of Linebender.
We'd like to reiterate our many thanks to Yevhenii Reizner for the years of hard work that he has poured into this and other crates.
The largest change in this release is the relicense to dual Apache-2.0 MIT.
It also includes support for the !important</code> CSS flag.</p>
Kurbo</h2>
Kurbo provides data structures and algorithms for curves and vector paths.</p>

kurbo#412</a>, kurbo#413</a>: Added utility methods to Size</code>, by @nils-mathieu</a>.</li>
</ul>
Color</h2>
Color</a> provides functionality for representing, converting, parsing, serializing, and manipulating colors in a variety of color spaces.
It closely follows the CSS Color Module Level 4</a> draft spec.</p>
The biggest update to Color in February was the addition of absolute color conversions, in color#139</a>.
This won't be visible for most users, but will be useful for those who need to convert between color spaces without changing the white point.
This will also be used in color#137</a>, which allows creating a theoretical black-body color from a temperature in Kelvin.</p>
Velato</h2>
We released Velato 0.5.0</a>, bringing compatibility with Vello 0.4.0.</p>
Kompari</h2>
Kompari</a> is a tool for visual inspection of snapshot tests.
parley#272</a> (in review) begins the exciting process of integrating Kompari into our existing projects.</p>
Research and Future Directions</h2>
Linebender has an origin story in being a very research oriented group, looking to break new ground.
While we are focused on shipping code today, we still have an eye on the future and how to be prepared for the new opportunities and technologies that are coming.</p>
While we didn't publish much in the way of artifacts in February, there was quite a bit of experimentation with computational geometry ideas related to #kurbo > Two-point shape control</a>, a technique that holds promise for faster and more accurate stroke expansion of cubic Béziers.
Stay tuned for more updates.</p>
Get Involved</h2>
We welcome collaboration on any of our crates.
This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>
We host an hour long office hours meeting each week where we discuss what's going on in our projects.
See #office hours in Zulip</a> for details.
We've also started a separate office hours time dedicated to the renderer collaboration, details also available at that link.</p>

Daniel and Olivier's "office hours" appointments can still be booked by anyone for open-ended discussion of the ecosystem.

See Daniel's schedule here</a>.</li>
See Olivier's schedule here</a>.</li>
</ul>
</li>
</ul>


Linebender in January 2025
2025-03-03T00:00:00+00:00
Linebender is an informal open-source organization working on various projects to advance the state of the art in GUI for the Rust programming language</a>.</p>
Xilem</h2>
Xilem is our flagship GUI project, inspired by SwiftUI.
It lets you build user interfaces declaratively by composing lightweight views together, and will diff them to provide minimal updates to a retained layer.</p>
Xilem saw decent direct progress in January and of course Xilem also benefits from all the progress in the rest of our stack which is detailed in later sections.</p>

xilem#420</a>, xilem#833</a>: Added emoji picker example.</li>
xilem#753</a>, xilem#828</a>: Added support for transforming widgets with kurbo::Affine</code>.</li>
xilem#806</a>: Made Pod</code> more flexible to allow creating a wider variety of wrapper widgets.</li>
xilem#840</a>: Updated to vello</code> 0.4.0.</li>
</ul>



Xilem emoji picker example app, showing various emoji options.
</figcaption>
</figure>
We also improved documentation, see e.g. xilem#818</a>.</p>
Masonry</h2>
Masonry is the widget system used by Xilem.
It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>
January was quite a busy month for Masonry with lots of significant changes landing, including both new features and improved old ones.
Most notable are the following highlights:</p>

xilem#737</a>: Added zstack</code> widget for composing widgets on top of each other.</li>
xilem#753</a>: Added support for transforming widgets with kurbo::Affine</code>.</li>
xilem#808</a>: AppDriver</code> now takes a reference to RenderRoot</code> for more flexibility.</li>
xilem#820</a>: Added a basic widget inspector for debugging.</li>
xilem#822</a>: Now widget focus is cleared when a user clicks outside of that focused widget.</li>
xilem#823</a>: When text of a text area is changed the cursor now gets moved to the end.</li>
xilem#827</a>: Refactored TreeArena</code>.</li>
xilem#830</a>: Improved handling of window focus.</li>
xilem#831</a>: Applied is</code>/has</code> naming convention more consistently across context method names.</li>
xilem#834</a>: Fixed crashing in run_single_update_pass</code>.</li>
xilem#837</a>: Removed a bunch of redundant Box</code> usage around Widget</code>.</li>
xilem#841</a>: Added features to help test Textbox</code>.</li>
xilem#848</a>: Reorganized modules.</li>
</ul>
We also improved documentation a lot, see e.g. xilem#787</a>, xilem#809</a>, xilem#811</a>, xilem#813</a>, xilem#815</a>, xilem#824</a>, xilem#826</a>, xilem#829</a>, xilem#832</a>, and xilem#835</a>.
Additionally a bunch of stale code got cleaned up.</p>
Vello</h2>
Vello is our GPU vector renderer.
It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>
We released Vello 0.4.0</a> which has a bunch of improvements and fixes from the preceding four months.
Among the improvements is the change from December that Vello now uses our own Color</a> library.
Highlights from the additions in January include image extend modes, alpha, and nearest neighbor sampling</a> and correct rendering of Apple Color Emoji</a>.</p>



Vello demo, showing image extend modes with nearest neighbor filtering.
</figcaption>
</figure>
Of course work didn't stop with this release.
In preparation for the next release we have already upgraded Vello to use wgpu 0.24.0</a>.</p>
Kurbo</h2>
Kurbo provides data structures and algorithms for curves and vector paths.</p>

kurbo#409</a>: Added turn_90</code> / rotate_scale</code> methods to Vec2</code>, and fixed the docs of Vec2::cross</code>.</li>
</ul>
Parley</h2>
Parley is a text layout library.
It handles text layout, mostly at the level of line breaking and resolving glyph positions.</p>
In January, a variety of layout edge cases have been fixed, support for bidirectional text was expanded, and testing of text layout and selection has improved.</p>

parley#238</a>: Updated to swash</code> 0.2.0, which paves the way for future no_std</code> support.</li>
parley#239</a>: Took another step towards supporting no_std</code> by enabling further testing in CI.</li>
parley#241</a>: Allows configuring the behavior of alignment for lines that overflow the container width.</li>
parley#244</a>: Added screenshots to selection area and cursor positioning tests.</li>
parley#245</a>: Enabled detection of the base direction of text layouts (left-to-right or right-to-left).</li>
parley#249</a>: Fixed issues related to line breaking around inline boxes, by new Linebender member Wim de With.</li>
parley#254</a>: Now adhering to the CSS white space model</a> in stripping leading white space following a new line in white space collapsing mode.</li>
parley#256</a>: Corrected the calculation of trailing white space, also by Wim de With.</li>
</ul>
Peniko</h2>
Peniko provides a set of shared types for concepts that are important for drawing/stroking paths, but excluding the path geometry itself (which can be found in Kurbo).
It includes types for brush styles (including gradient) and color.</p>
We released Peniko 0.3.1</a> which was a simple maintenance release with tweaked docs and updated dependencies.</p>
Color</h2>
Color</a> provides functionality for representing, converting, parsing, serializing, and manipulating colors in a variety of color spaces.
It closely follows the CSS Color Module Level 4</a> draft spec.</p>
We released Color 0.2.2</a>, soon followed by Color 0.2.3</a>, the latter of which added easier methods to convert 8-bit colors from byte streams (for use with GPUs) and to other color representations in color#135</a> and color#136</a>.
This release also saw the addition of the ACES2065-1 color space in color#124</a>.</p>
Velato</h2>

velato#49</a>: Updated to vello</code> 0.4.0.</li>
</ul>
Vello SVG</h2>
We released Vello SVG 0.6.0</a> which most notably includes:</p>

vello_svg#50</a>: Added support for raster images to be completely disabled via a feature flag.</li>
vello_svg#53</a>: Updated to vello</code> 0.4.0.</li>
</ul>
Kompari</h2>
Kompari</a> is a tool for visual inspection of snapshot tests.</p>

kompari#13</a>: Interactive review (in HTML).</li>
kompari#14</a>: Rework of repository layout.</li>
kompari#16</a>: Alternative diff views.</li>
</ul>
Resvg</h2>

resvg#873</a>: Added the stylesheet option to the C API.</li>
resvg#878</a>: Updated to svgtypes</code> 0.15.3.</li>
</ul>
SVG Types</h2>
We released SVG Types 0.15.3</a> with a few minor fixes.
This is also the first release under the stewardship of Linebender.</p>
Tiny Skia</h2>

tiny-skia#146</a>: Added scale_by</code> / scale_to</code> methods to Size</code>.</li>
</ul>
SimpleCSS</h2>
We released SimpleCSS 0.2.2</a> with no_std</code> support, updated docs clarifying Linebender involvement, and to test run the publishing workflow.</p>
Research and Future Directions</h2>
Linebender has an origin story in being a very research oriented group, looking to break new ground.
While we are focused on shipping code today, we still have an eye on the future and how to be prepared for the new opportunities and technologies that are coming.</p>
While Vello has unmatched rendering speed thanks to its GPU-driven architecture, there are two practical tradeoffs: it can require unpredictable amounts of memory, and it doesn't work on downlevel GPUs with weak or nonexistent support for compute shaders.
Raph Levien has been exploring a possible hybrid CPU/GPU direction for Vello to address these issues.
Read the design doc</a>, follow the Zulip thread</a>, or stay tuned for more developments.</p>
Get Involved</h2>
We welcome collaboration on any of our crates.
This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>
We host an hour long office hours meeting each week where we discuss what's going on in our projects.
See #office hours in Zulip</a> for details.</p>

Daniel and Olivier's "office hours" appointments can still be booked by anyone for open-ended discussion of the ecosystem.

See Daniel's schedule here</a>.</li>
See Olivier's schedule here</a>.</li>
</ul>
</li>
</ul>


Linebender in December 2024
2025-01-13T00:00:00+00:00
Linebender is an informal open-source organization working on various projects to advance the state of the art in GUI for the Rust programming language</a>.</p>
We'd like to wish everyone a happy New Year!</p>
Peniko</h2>
Peniko provides a set of shared types for concepts that are important for drawing/stroking paths, but excluding the path geometry itself (which can be found in kurbo).
It includes types for brush styles (including gradient) and color.</p>
Last month, we continued down the path to supporting a richer color model and wider gamuts.
We released Peniko 0.3.0</a> which replaces the old color code with our new Color</a> crate.</p>

peniko#63</a>: Use the Color crate</li>
peniko#71</a>: Gradient</code> now tracks a hue direction and interpolation color space</li>
peniko#77</a>: Add x/y extend modes and quality hint to images</li>
</ul>
Color</h2>
Color provides functionality for representing, converting, parsing, serializing, and manipulating colors in a variety of color spaces.
It closely follows the CSS Color Module Level 4</a> draft spec.</p>
Last month, we released Color 0.2.0</a> and Color 0.2.1</a>.</p>
The release of Color 0.2.0 contained a significant amount of work to enable use with Peniko and the rest of the Linebender stack.</p>
Color 0.2.1 included improvements to parsing.</p>

color#109</a>: Make color parsing case insensitive</li>
color#111</a>: Add FromStr</code> impl for AlphaColor</code>, DynamicColor</code>, OpaqueColor</code>, and PremulColor</code></li>
</ul>
We encourage people to give Color</a> a try and let us know how it goes.</p>
Vello</h2>
Vello is our GPU vector renderer.
It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>
Vello is now using the new Peniko 0.3 release along with the Color crate.</p>

vello#757</a>: Remove buffer_labels</code> feature as it is no longer optional</li>
vello#761</a>: Remove work-around for const</code> / let</code> globals in WGSL</li>
vello#768</a>: Migrate to notify-debouncer-full</li>
vello#774</a>: Initialize wgpu InstanceDescriptor</code> from environment</li>
</ul>
Parley</h2>
Parley is a text layout library.
It handles text layout, mostly at the level of line breaking and resolving glyph positions.</p>

parley#193</a>: Added snapshot tests for text selection areas and cursor positioning</li>
parley#192</a>: Changed the PlainEditor</code> abstraction to reduce unneeded work</li>
parley#224</a>: Exports the text selection area, ensuring that input selection boxes don't overlap content</li>
parley#227</a>: Adds infrastructure for easy to understand tests for text editing functionality</li>
</ul>
Kompari</h2>
Kompari</a> is a tool for visual inspection of snapshot tests.
This project is a new addition to Linebender, generously contributed by Ada Böhm</a> and is currently in pre-alpha.</p>



A report for snapshot test, generated by Kompari.</p>
</figcaption>
</figure>
We plan for Kompari to standardise and improve the developer experience of snapshot tests in Linebender (and beyond).
It can generate reports which summarises failed snapshot tests, and will also contain functionality for interactive blessing of new snapshots.
This reporting can be integrated into a repository as an xtask:</p>
cargo</span> xtask report
</span></code></pre>
Kompari also includes a standalone CLI, for projects which don't use the xtask pattern or are trialling Kompari.</p>
In December, we added initial functionality and established CI in the repository.
Ongoing work includes:</p>

kompari#12</a>: Refactoring the project to make it more modular</li>
kompari#13</a>: Interactive test blessing</li>
</ul>
Masonry</h2>
Masonry is the widget system used by Xilem.
It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>
Updates to Parley integration and usage for IME and text editing:</p>

xilem#766</a>: Update to upstream unbatched PlainEditor</li>
xilem#767</a>: Stop IME just before shutting down</li>
xilem#768</a>: Clear compose in TextArea::reset_text</code></li>
xilem#785</a>: Improve IME area reporting and set IME area in TextArea</code></li>
</ul>
The new tree arena landed and saw some performance improvements:</p>

xilem#752</a>: Tree arena</li>
xilem#772</a>: Use hashmap to track tree arena node children</li>
xilem#774</a>: Use hashbrown</code> as drop-in replacement to optimize tree access</li>
</ul>
We updated to start using the Color crate:</p>

xilem#798</a>: Update to git Parley and Vello (uses Color)</li>
xilem#800</a>: Use palette</code> and Color</code> from top level Masonry and Xilem</li>
</ul>
Miscellaneous:</p>

xilem#777</a>: Render one frame before showing the window to avoid flashing</li>
xilem#795</a>: Sized Box: Use a brush for the border</li>
</ul>
Xilem</h2>
Xilem is our flagship GUI project, inspired by SwiftUI.
It lets you build user interfaces declaratively by composing lightweight views together, and will diff them to provide minimal updates to a retained layer.</p>

xilem#797</a>: The text colour and other properties inside buttons can now be customised</li>
</ul>
Research and Future Directions</h2>
Linebender has an origin story in being a very research oriented group, looking to break new ground.
While we are focused on shipping code today, we still have an eye on the future and how to be prepared for the new opportunities and technologies that are coming.</p>
We have a couple of active and ongoing research projects:</p>

Raph Levien on SIMD, stroke expansion, and new rendering approaches for Vello.</li>
Joe Neeman on boolean path operations.</li>
A potential revival of the Piet project, discussed on Zulip</a>.</li>
</ul>
Get Involved</h2>
We welcome collaboration on any of our crates.
This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>
We host an hour long office hours meeting each week where we discuss what's going on in our projects.
See #office hours in Zulip</a> for details.</p>

Daniel and Olivier's "office hours" appointments can still be booked by anyone for open-ended discussion of the ecosystem.

See Daniel's schedule here</a>.</li>
See Olivier's schedule here</a>.</li>
</ul>
</li>
</ul>


Linebender in November 2024: color!
2024-12-18T00:00:00+00:00
Linebender is an informal open-source organization working on various projects to advance the state of the art in GUI for the Rust programming language</a>.</p>
This month's update contains some surprises, even to us!</p>
Color</h2>
When we published the update for October, 2024</a>, we had already been discussing starting a new color-focused crate, but hadn't yet created a repository.</p>
We may have a dedicated blog post about the color</code> crate in the future and laying out some of the motivations, but we'll go over it a bit here.</p>
Linebender, among other things, believes in helping build solid foundations for people building user interfaces and working in graphics, in the Rust programming language (and on GPUs).
Upon seeing a problem, we prefer to produce a focused crate that solves that problem and that can be used by others within the Rust ecosystem.
Color is one such area.
It is much harder than it may appear at first, with many complicating factors like what should be done by a basic color struct, what color spaces to support, and whether or not to support color formats used in print (like CMYK).</p>
We looked around at a wide variety of crates in various stages of maintenance and development, their feature sets, the "weight" of those crates, and how closely they fit in with what we would need in Vello, Tiny Skia, Resvg, SVG Types, Masonry, and Xilem.
We decided to do a crate based on the CSS Color Module Level 4</a> draft specification, with support for a limited number of additional color spaces.</p>
We released an alpha of this new crate as Color 0.1.0</a> on November 21, 2024.
The documentation lays out more of the scope, goals, and main types provided by the crate.</p>
Linebender

Linebender in 2026 Q1

Fearless SIMD</h2> Fearless SIMD is our SIMD infrastructure library. It provides a solid, portable way to write SIMD code that compiles to Wasm, AArch64, x86, and x86_64.</p>

Linebender in December 2025

Parley</h2> Parley is a text layout library. It handles text layout, mostly at the level of line breaking and resolving glyph positions.</p>

Kurbo</h2> Kurbo provides data structures and algorithms for curves and vector paths.</p>

Peniko</h2> Peniko is a 2D graphics type library which provides a set of generic types that define styles for rendering and composition.</p>

Fearless SIMD</h2> Fearless SIMD is our SIMD infrastructure library. It provides a solid way for writing SIMD operations portably across Wasm, AArch64, x86, and x86_64.</p>

Velato</h2> Velato is our Lottie render library. The goal is to provide coverage of the large Lottie spec, up to what Vello can render, for use in interactive graphics.</p>

Resvg</h2> Resvg is our fast, small, portable SVG library.</p>

SimpleCSS</h2> SimpleCSS is a basic CSS 2.1 parser and selector.</p>

Druid</h2> Druid is a GUI library which was a predecessor to Xilem, and an ancestor of Masonry.</p>

Get Involved</h2> We welcome collaboration on any of our crates. This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>

Linebender in November 2025

Parley</h2> Parley is a text layout library. It handles text layout, mostly at the level of line breaking and resolving glyph positions.</p>

Fearless SIMD</h2> Fearless SIMD is our SIMD infrastructure library. It provides a solid way for writing SIMD operations portably across WASM, Aarch64, x86, and x86_64.</p>

Bevy Vello</h2> Bevy Vello is our Bevy integration for Vello. The goal is to provide support for rendering scenes, text, SVGs, and Lotties in the Bevy game engine.</p> A lot of work was done to update Bevy Vello for Bevy 0.17.</p>

Get Involved</h2> We welcome collaboration on any of our crates. This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>

Linebender in October 2025

Linebender in September 2025

Parley</h2> Parley is a text layout library. It handles text layout, mostly at the level of line breaking and resolving glyph positions.</p>

Get Involved</h2> We welcome collaboration on any of our crates. This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>

Linebender in August 2025

Vello</h2> Vello is our GPU vector renderer. It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>

Masonry</h2> Masonry is the widget system developed by Linebender. It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>

Xilem</h2> Xilem is our flagship GUI project, inspired by SwiftUI, which uses Masonry for its widgets. It lets you build user interfaces declaratively by composing lightweight views together, and will diff them to provide minimal updates to a retained layer.</p>

Get Involved</h2> We welcome collaboration on any of our crates. This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>

Linebender in July 2025

Masonry</h2> Masonry is the widget system developed by Linebender. It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>

Get Involved</h2> We welcome collaboration on any of our crates. This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>

Linebender in June 2025

Linebender in May 2025

Masonry</h2> Masonry is the widget system developed by Linebender. It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>

Vello</h2> Vello is our GPU vector renderer. It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>

Get Involved</h2> We welcome collaboration on any of our crates. This can include improving the documentation, implementing new features, improving our test coverage, or using them within your own code.</p>

A plan for SIMD

Linebender in April 2025

Xilem</h2> Xilem is our flagship GUI project, inspired by SwiftUI, which uses Masonry for its widgets. It lets you build user interfaces declaratively by composing lightweight views together, and will diff them to provide minimal updates to a retained layer.</p>

Vello</h2> Vello is our GPU vector renderer. It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>

Linebender in March 2025

Vello</h2> Vello is our GPU vector renderer. It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>

Towards fearless SIMD, 7 years later

Linebender in February 2025

Masonry</h2> Masonry is the widget system used by Xilem. It provides a non-opinionated retained widget tree, designed as a base layer for high-level GUI frameworks.</p>

Vello</h2> Vello is our GPU vector renderer. It can draw large 2D scenes with high performance, using GPU compute shaders for most of the work.</p>

Linebender in January 2025

Peniko</h2> Peniko provides a set of shared types for concepts that are important for drawing/stroking paths, but excluding the path geometry itself (which can be found in Kurbo). It includes types for brush styles (including gradient) and color.</p>

Velato</h2>
Velato is our Lottie render library. The goal is to provide coverage of the large Lottie spec, up to what Vello can render, for use in interactive graphics.</p>
We released Velato 0.8</a> and 0.8.1</a>. 🎉</p>
