.NET 10 桌面 UI 框架的范式演进：Jalium.UI 与 MewUI 架构深度对比

【本文借助AI 编写】

.NET 桌面开发生态的战略性分化与重构

随着.NET 平台的持续迭代，特别是在跨平台多设备应用 UI（.NET MAUI）被确立为官方主要演进方向之后，桌面应用程序的开发范式经历了深刻的重构 1。传统的 Windows 专属框架（如 Windows Forms 和 Windows Presentation Foundation, WPF）虽然在企业级应用中依然占据主导地位，但它们从根本上受制于仅限 Windows 的生态以及对动态代码生成和反射的重度依赖 3。现代跨平台框架（如 Avalonia UI 和 Uno Platform）虽然通过高度抽象的渲染层解决了跨平台问题，但由于深度绑定了庞大的 C++ 图形底层库（例如 SkiaSharp），导致其在执行原生提前编译（NativeAOT）和代码裁剪（Trimming）后，即便是最基础的应用程序，其独立二进制文件体积依然在 30 MB 到 80 MB 之间徘徊 3。
这种生态现状导致了一个两极分化的技术困境：开发者要么被迫接受庞大的运行时依赖与分发体积，要么只能放弃现代化的 UI 框架。为了打破这一僵局，开源社区基于最新的.NET 10 底层特性，演化出了两条截然相反的破局路径。本报告将对这两条路径的代表性产物——Jalium.UI 与 MewUI——进行详尽、深入且穷尽细节的比较研究。
Jalium.UI 代表了“重型现代化”路线，它是一个完全由 GPU 加速、深度整合了类 WPF 对象模型与 Web 时代 Razor 语法扩展的跨平台重量级框架 6。而 MewUI 走的是“极限轻量化”路线，由社区开发者 Youngjae Song（社区 ID: aprillz / al6uiz）发起，定位为一个实验性的、代码优先的轻量级.NET GUI 框架，专为解决小型桌面实用工具的分发体积问题而生，其核心目标是在无任何外部 C++ 图形 DLL 依赖的前提下，实现 2.5 MB 至 4.0 MB 的极致原生编译体积 3。
通过剖析两者的渲染管线、状态绑定机制、标记语言编译器支持以及底层内存管理策略，本文不仅将揭示两者在具体工程实现上的巨大差异，更将探讨现代.NET 底层基础设施（如源生成器、栈分配机制、SIMD 硬件指令集）如何赋能框架开发者构建下一代桌面用户界面。

Jalium.UI：基于 GPU 加速的富媒体跨平台架构

Jalium.UI 的核心定位是为那些需要构建复杂、高性能且具备极高视觉保真度的企业级桌面与移动端应用提供基础设施 6。在其名为 VeryJokerJal 的 GitHub 组织下，该框架展现出了一个极其庞大且高度模块化的技术堆栈，涵盖了从底层跨平台窗口抽象到高层 MVVM 路由的方方面面 6。

JALXAML 标记语言与 Razor 语法的深度融合

在传统的 WPF 或 Avalonia 开发中，XAML（可扩展应用程序标记语言）强制推行了视图（View）与逻辑（ViewModel）的严格分离。然而，这种分离在实际工程中往往导致大量的样板代码（Boilerplate）。例如，开发者必须编写大量的 IValueConverter（值转换器）来实现最基础的布尔值到可见性（Visibility）的转换，或者依赖极其冗长的 VisualStateManager 来处理 UI 的条件渲染。
Jalium.UI 通过引入其专有的 JALXAML 解析引擎，从根本上颠覆了这一范式 6。JALXAML 最大的架构创新在于它将 Web 开发中广泛使用的 Razor 风格语法作为“语法糖”无缝叠加在现有的 {Binding...} 基础架构之上 6。开发者可以在 XAML 标签内直接使用 @Path 进行属性访问，使用 @(expr) 注入动态表达式，或者使用 @{... } 定义混合文本模板 6。
更为深刻的是，JALXAML 支持块级控制流指令，如 @if(expr){} 6。在底层的视觉树（Visual Tree）构建过程中，这意味着框架不再需要实例化大量默认隐藏的控件节点并驻留在内存中等待状态触发。如果 @if 表达式的求值结果为假，该 UI 元素在编译期生成的构建树中将被直接忽略，这极大地优化了复杂页面的内存占用和冷启动解析时间。
为了确保这种灵活的动态语法不会引入运行时的反射性能惩罚，Jalium.UI 深度依赖基于 Roslyn 编译器的源生成（Source Generator）技术 6。其专属的 Jalium.UI.Xaml.SourceGenerator 模块和 Jalium.UI.Build MSBuild 任务在应用程序的编译阶段拦截 JALXAML 文件，将所有 Razor 表达式和绑定逻辑解析并生成为强类型的、静态的 C# 后置代码 6。这种“编译期绑定”机制确保了即使是极其复杂的界面逻辑，在运行时也能以原生的 C# 执行速度运行，完全消除了传统 XAML 引擎中的动态字符串查找开销。

硬件原生的多端图形管线与视觉合成

在图形渲染层面，Jalium.UI 放弃了对操作系统默认绘图 API 的过度依赖，构建了一个直达底层硬件的 GPU 原生渲染管线 6。根据宿主操作系统的不同，它实现了多个平台原生的渲染后端（Backend）：在 Windows 平台上对接 DirectX 12，在 Linux 平台上对接 Vulkan，而在 macOS 平台上则利用 Metal 6。对于缺乏现代 GPU 支持的极端环境，它亦提供了一个基于 CPU 的软件渲染回退模块 (jalium.native.software) 6。
这种低级别的 GPU 控制权使得 Jalium.UI 能够在框架内核中实现高度复杂的视觉着色器（Shaders）6。文档明确指出，该框架原生支持液态玻璃（liquid glass）、背景模糊（backdrop blur）、亚克力（acrylic）以及云母（mica）等高级材质效果，并内置了过渡着色器（transition shaders）6。这些特效要求渲染引擎能够实时抓取操作系统底层的窗口背景像素，通过像素着色器进行高斯模糊和色彩混合，这在传统的 WinForms 甚至基础版的跨平台框架中是极难高效实现的。
在排版与文本渲染这一桌面 UI 最具挑战性的领域，Jalium.UI 展现了企业级的严谨性。它集成了 ClearType 亚像素级文本渲染技术以确保在低 DPI 显示器上的清晰度 6。更为关键的是，为了解决 Linux 和 Android 平台上系统自带字体渲染引擎的差异性与局限性，Jalium.UI 封装了一个跨平台的独立文本引擎 (jalium.native.text)，底层依赖于业界标准的 FreeType（用于字形轮廓光栅化）与 HarfBuzz（用于复杂的跨语言文本塑形）6。这保证了无论是拉丁语系、阿拉伯语还是复杂的东亚字符集，在所有操作系统上都能呈现出像素级一致的完美排版。

对象模型与企业级控件生态

尽管在渲染和标记语法上进行了激进的创新，Jalium.UI 的核心抽象依然致敬了 WPF 的经典设计模式 6。其基础模块 Jalium.UI.Core 实现了开发者熟悉的 DependencyObject、Visual、UIElement 以及布局系统 11。依赖属性（Dependency Property）系统的保留，意味着诸如属性值继承（例如子控件自动继承父级窗口的字体设置）、复杂的动画时间线绑定以及多级样式覆盖等企业级特性得以完整保留。
在此基础之上，Jalium.UI.Controls 提供了一个极其庞大且功能完备的控件库，包含 80 多种控件，覆盖了从基础按钮到极度复杂的数据可视化与布局容器 6。特别值得注意的是，该框架原生内置了图表（Charts）、微软 Office 风格的 Ribbon 导航、停靠管理器（Docking）、支持触控笔输入的 InkCanvas、跨平台的终端控件（Terminal），以及通过 jalium.native.browser 模块实现的 WebView2 现代浏览器内核集成 6。对于企业合规性，Jalium.UI 通过提供自动化对等体（automation peers），全面支持了 UIA 无障碍访问标准，确保屏幕阅读器等辅助设备能够正常工作 6。
其官方示例项目 Jalium.UI.Gallery 充分展示了这种架构在复杂模块化应用中的潜力 8。该画廊应用采用了完整的“全应用模块化（Full App Modular）”模板，深度整合了 PrismCompat MVVM 架构模式与控制反转/依赖注入容器 8。视图模型继承自底层的 ViewModelBase 和 RegionViewModelBase，确保了应用状态与生命周期的严格管理 8。在主题管理方面，通过 AppTheme.jalxaml 中定义的动态资源字典与 GalleryTheme.cs 实现的实时调色板，展示了其能够在运行时无缝切换深色/浅色模式的能力 8。
在实际的工业界应用案例中，可以观察到 SoundFlow 等高性能音频处理软件采用了 Jalium.UI 12。由于 SoundFlow 专注于实时音频录制、处理、混音以及支持 SIMD 指令的内存管理，其对 UI 框架的要求是：既要能提供极高的数据刷新率以展示频段分析，又绝不能因为界面渲染的开销（如频繁的垃圾回收）导致底层音频处理线程发生中断或延迟 12。Jalium.UI 凭借其底层 GPU 加速和静态生成的 JALXAML 管线，成功满足了这一极端性能场景的需求。

MewUI：面向 NativeAOT 的极限裁剪与栈上渲染

如果说 Jalium.UI 是为了构建下一个 Visual Studio 或数字音频工作站，那么 MewUI 则是为了拯救那些只需要几个按钮、复选框和输入框的系统微型工具 3。在 MewUI 出现之前，开发者如果想用 C# 编写一个修改注册表的工具或者游戏解包器，必须要求用户安装数百兆的.NET 运行时环境 4。NativeAOT 技术虽然允许将.NET 应用程序编译为独立的本机机器码，但它对运行时的动态行为（如大量使用反射）极其敏感 3。由于 WPF 和 WinForms 高度依赖反射，它们被彻底排除在 NativeAOT 支持之外 3。
社区开发者 Youngjae Song（GitHub 活跃账号为 aprillz）在面对这一痛点时，开启了一项为期约两个月的实验性项目 4。值得一提的是，MewUI 的开发过程极具现代工程特色：作者主要通过与人工智能模型（GPT）的迭代式提示（iterative prompting）来生成代码，同时自己掌控整体的架构决策与代码审查 5。其最终成果 MewUI，成功地将一个完整的跨平台 GUI 框架及其依赖项压缩到了 2.2 MB 至 4.0 MB 之间 3。

抛弃反射与 XAML：代码优先与强类型状态机

MewUI 能够实现如此极致的体积压缩，其最根本的架构决策是完全彻底地抛弃了 XAML 3。任何形式的标记语言，无论在构建时如何优化，最终都不可避免地需要在运行时维护复杂的元数据树，这直接阻碍了.NET 链接器（Trimmer）剔除未使用的代码。MewUI 选择了“代码优先（Code-First）”的 Fluent C# Markup API 3。开发者通过链式调用的 C# 方法直接构建界面元素树，这使得编译器能够进行最深度的静态分析，任何未在 C# 代码中被显式引用的控件分支或框架子系统，在 NativeAOT 编译阶段都会被安全、彻底地剔除，从而确保了极小的二进制载荷。
在数据绑定层面，MewUI 放弃了传统的依赖属性系统，拒绝使用任何依赖于字符串路径查找和运行时反射的机制（因为这会触发严重的 NativeAOT 裁剪警告并使二进制文件膨胀）3。取而代之的是，它实现了一个完全基于强类型泛型代理的状态机：ObservableValue 3。这种设计类似于响应式编程（Reactive Programming），界面控件的属性直接绑定到具体的内存对象引用上。因为所有绑定都在编译期得到了静态验证，运行时无需维持庞大的属性字典，这不仅保证了 100% 的 AOT 安全性，更极大地降低了运行时的内存碎片和对象分配压力。
为了维持轻量化，MewUI 严格限定了其作用域（Scope）。它主动牺牲了大规模数据绑定、复杂的 WPF 风格动画合成管道以及重型的媒体集成功能 3。在其支持的控件矩阵中，主要包含基础的输入和展示控件（如 TextBox, MultiLineTextBox, ComboBox, TreeView, Slider, TabControl 等），以及最核心的布局容器（Grid, StackPanel, DockPanel, WrapPanel, SplitPanel）3。通过这种断臂求生的策略，MewUI 在基于 NativeAOT 的 64 位 Windows 环境中，实现了令人咋舌的性能指标：首帧渲染时间（Time to first frame）仅需约 178 毫秒，工作集内存占用（Working set）控制在约 40 MB，私有字节（Private bytes）仅为 55 MB 4。

MewVG：零依赖的托管级向量图形引擎

MewUI 最具技术含量的突破在于其完全摆脱了对 SkiaSharp 等庞大 C++ 底层图形库的依赖。为了实现跨平台的硬件加速渲染，Youngjae Song 移植并构建了一个名为 MewVG 的跨平台、全托管.NET 向量图形库，其核心算法衍生自轻量级的开源库 NanoVG 3。
MewVG 利用 OpenGL（在 Windows 和 Linux 上）和 Metal（在 macOS 上）作为底层桥梁，但其内部实现了大量专门针对现代.NET 环境优化的极客级技术：

1. 零堆分配的内联数组几何栈（InlineArray Zero-Heap Allocation）：在绘制复杂的矢量路径（如贝塞尔曲线）时，计算机会生成海量的瞬态坐标数据。如果这些数据被分配在托管堆（Managed Heap）上，将导致垃圾回收器（GC）极其频繁地触发第 0 代（Gen 0）回收，进而引发渲染循环中的掉帧和卡顿。MewVG 利用了.NET 最新的 InlineArray 结构，将这些瞬态的路径坐标完全分配在线程栈（Stack）上。这意味着当渲染方法结束时，内存会立即自动释放，对 GC 施加的压力为零 3。
2. GPU 模板缓冲区嵌套裁剪（Stencil Buffer Clipping）：复杂的 UI 往往包含多层嵌套的滚动区域和圆角。传统方法需要消耗大量 CPU 周期进行像素级掩码计算。MewVG 巧妙地利用了硬件 GPU 的模板缓冲区（Stencil Buffer），通过奇偶填充规则（Odd-Even Fill Rule）和模板掩码，在单次渲染通道（Single Pass）中直接让 GPU 处理所有复杂的几何裁剪，避免了昂贵的像素回读（Pixel Read-backs）开销 3。
3. 对象空间细分缓存（Object-Space Tessellation Cache）：GPU 无法直接渲染曲线，必须将其细分为三角形（Tessellation）。对于面板边框等静态的矢量几何图形，MewVG 集成了 LibTessDotNet（libtess2 的 C# 移植版），在对象空间中将细分后的顶点数据缓存起来 3。这使得 CPU 只需要在 UI 元素初次创建或尺寸改变时计算一次细分，后续的所有帧都直接将缓存好的顶点送入 GPU，极大降低了 CPU 的计算负载。
4. 现代互操作与纹理优化：引擎全面摒弃了传统的 DllImport 特性，转而使用 C# 源生成的 LibraryImport 来声明 P/Invoke 3。这不仅完全兼容 NativeAOT，还生成了无反射的静态本机互操作代理代码。此外，MewVG 支持原生 BGRA 纹理，避免了 CPU 重新排列颜色通道的耗时操作，并通过生成带有预乘 Alpha（Premultiplied Alpha）的 Mipmap 来消除缩放时的伪影和黑边现象 3。

SIMD 硬件指令加速与纯软件回退

MewUI 的设计考虑到了极端恶劣的部署环境（如 Windows PE 恢复盘、极度受限的虚拟机或缺乏独立显卡驱动的老旧 Windows 7 系统）3。为此，它提供了一个纯粹基于 CPU 计算的 GDI 渲染后端（Aprillz.MewUI.Backend.Gdi）3。
通常情况下，在 CPU 上进行纯软件的逐像素 Alpha 混合和渲染是极其缓慢的。为了打破这一瓶颈，MewUI 深度整合了单指令多数据流（SIMD）硬件指令集（通过 System.Runtime.Intrinsics 命名空间）3。在支持 AVX2 或 SSE4.1 指令集的 CPU 上，MewUI 能够将四个独立的 32 位 BGRA 像素同时加载到一个单一的 128 位硬件寄存器（Vector128）中 3。这使得 CPU 能够在单条时钟周期内并行执行四个像素的色彩混合与 Alpha 乘法数学运算，从而以数倍的效率极大地提升了纯软件渲染的吞吐量，确保了在没有 GPU 参与的情况下界面依然能够保持流畅 3。

双重抽象架构与离屏渲染的潜力

MewUI 在架构设计上实现了操作系统平台宿主（IPlatformHost）与渲染后端（IGraphicsFactory）的彻底解耦 3。Win32PlatformHost 负责处理 Windows 消息循环，X11PlatformHost 负责 Linux 窗口系统，同时还有 macOS 的宿主实现 3。特别是在 Linux 环境下，为了坚守极小体积的原则，MewUI 避免了引入庞大的 P/Invoke 绑定库去调用 GTK 或 Qt 的原生对话框，而是创造性地通过调用外部系统实用程序（如 GTK 的 zenity 或 KDE 的 kdialog）来显示消息框或文件选择对话框 3。
这种将系统句柄与绘制上下文物理隔离的架构，赋予了 MewUI 另一项极为强大的能力：原生的离屏渲染（Offscreen Rendering）支持 3。由于 IGraphicsContext 完全不在乎它正在往哪里绘制像素，开发者可以轻易地命令 MewUI 将完整的可视化控件树直接渲染到系统内存或显存（VRAM）中的一块像素缓冲区内 3。这一特性使得 MewUI 成为游戏引擎（如基于 DirectX 或 Vulkan 的自研 3D 引擎）中实现复杂交互式 HUD（抬头显示器）或内部配置叠加层（Overlay）的完美中间件。对于游戏引擎而言，引入几十兆的 Avalonia 是不可接受的性能灾难，而 3 MB 的 MewUI 则成为了一个理想的轻量级解决方案。
其作者也已经利用该框架在真实场景中进行了工程验证，例如重写了屏幕控制工具 DisplayBlackout 的端口（DisplayBlackout.MewUI），以及维护诸如 PeaceWalkerTools 和 TwinSnakesTools 等面向游戏 MOD 制作和解包的纯功能性微工具 7。开发者甚至可以通过一行极客指令 curl -sL -o - | dotnet run - 直接从 GitHub 下载并在本地内存中即时编译运行 MewUI 的 Gallery 示例应用，无需克隆仓库或配置复杂的项目结构，这彰显了其极其轻量和无侵入的特性 4。

核心架构维度的多重对比分析

为了更清晰地评估两种范式的差异，以下从多个技术维度对 Jalium.UI 与 MewUI 进行直接比较。

表 1：核心架构与设计哲学对比

由表 1 可见，两者在底层设计哲学上存在不可调和的分歧。Jalium.UI 试图通过改进编译期工具（Roslyn 源生成）来保留 XAML 带来的声明式开发体验，使得 MVVM 模式和 UI 设计师/程序员分离的协作模式依然可行。而 MewUI 认为，为了实现单文件极致体积，必须切断与 WPF 历史包袱的任何联系，直接回归到最原始、最可控的纯代码层面。

表 2：渲染管线与图形系统对比

在图形系统的构建上，Jalium.UI 选择了“集成最佳实践”的道路，它并不避讳引入外部的重量级库（如 HarfBuzz），因为它的目标受众是需要构建具备商业软件质感（如具备复杂的透明亚克力侧边栏、能够完美支持多语言复杂语系）的开发者。MewUI 的技术攻坚则全部集中在如何用纯净的 C# 代码榨干底层硬件的性能，其通过将 NanoVG 的 C 语言内存管理转换为基于栈的 InlineArray 结构，展现了现代.NET 极客级的底层操控力。

表 3：性能特征与分发模型对比

在性能特征上，两者的适用场景泾渭分明。如果你在开发一个类似于 Photoshop 的软件，Jalium.UI 启动时多消耗的几秒钟和运行时的数百兆内存是完全可以被容忍的。但如果你只是开发一个用于调节显示器亮度（类似 DisplayBlackout.MewUI）或解包特定游戏资源（类似 PeaceWalkerTools）的小工具，用户期望的是双击后瞬间弹出窗口且不留下系统垃圾，此时 MewUI 的分发模型和极致体积就成为了唯一解。

对.NET 生态演进的深层启示

通过对比 Jalium.UI 与 MewUI，我们可以洞察到.NET 10 生态系统底层基础设施演进的三个关键趋势：
第一，微软官方框架的退场与社区细分领域的繁荣。.NET MAUI 作为一个大一统的框架，其重心不可避免地向移动端（iOS/Android）倾斜，这导致它在桌面端的表现和轻量化诉求上频频妥协。Jalium.UI 和 MewUI 的出现，证明了开源社区已经具备了基于最新的底层 CLR（公共语言运行时）独立构建完整渲染管线的能力，桌面 UI 正在从“一招鲜吃遍天”向高度定制化的垂直领域发展。
第二，底层 C# 性能对系统级语言的逼近。过去，开发高性能图形引擎或规避垃圾回收（GC）暂停，通常需要求助于 C++ 或 Rust。然而，MewUI 通过 MewVG 引擎证明了，只要开发者能够熟练掌握并组合运用.NET 带来的新特性（如源生成的 LibraryImport 互操作、SIMD Vector128 硬件指令流并发、以及用于规避堆分配的 InlineArray 栈内存结构），完全可以在托管语言中实现接近系统级语言的运行效率和内存确定性。
第三，编译期工具链（AOT 与源生成器）正在重塑软件架构。无论是 Jalium.UI 利用源生成器将包含 Razor 语法的 JALXAML 转换为静态 C# 代码，还是 MewUI 为了顺应 NativeAOT 裁剪规则而彻底重构状态绑定机制，都表明现代.NET 架构设计的核心矛盾，已经从“如何优化运行时的反射效率”转移到了“如何将更多的动态逻辑提前转移到编译期解析”。

结论与技术选型建议

综上所述，Jalium.UI 与 MewUI 代表了现代.NET 10 桌面应用开发的两个极端，两者之间不存在绝对的优劣之分，而是针对完全不同的业务领域和部署约束给出的极致答案。
Jalium.UI 是一头装备精良的“重装巨兽”。它通过创新的 JALXAML 和 Razor 语法融合，极大降低了传统 MVVM 开发中的心智负担。其直接对接图形硬件底层的渲染管线，结合企业级的跨平台文本引擎（FreeType/HarfBuzz）和丰富的控件库生态（包括 WebView2 和复杂图表），使其成为开发大型、高保真、数据密集型商业软件的理想选择。如果项目的核心诉求是极致的视觉体验、完善的辅助功能（UIA）以及高生产力的声明式 UI 开发，那么 Jalium.UI 是不可多得的现代基础设施。
MewUI 则是专门猎杀系统微型工具开发痛点的一把“手术刀”。作者通过摒弃 XAML 框架、重构基于泛型的状态代理，并手写优化了以零堆栈分配和 SIMD 加速为核心的 MewVG 矢量图形引擎，生硬地在庞大的.NET 生态中劈出了一条实现单文件 3MB 以下超轻量体积的血路。对于 DevOps 内部工具开发、轻量级游戏 MOD 工具、系统控制台扩展，或者是任何受限于极严苛分发体积与启动时间要求的项目，MewUI 提供了一种此前在 C# 生态中几乎不可能实现的跨平台原生级体验。

引用的链接

1. .NET Multi-platform App UI (.NET MAUI) | .NET - Microsoft .NET, https://dotnet.microsoft.com/en-us/apps/maui
2. .NET Multi-platform App UI documentation - .NET MAUI | Microsoft Learn, https://learn.microsoft.com/en-us/dotnet/maui/?view=net-maui-10.0
3. MewUI 项目：面向NativeAOT 的超轻量级.NET GUI 架构、底层图形 ..., https://www.cnblogs.com/shanyou/p/20064719
4. MewUI – a lightweight .NET UI library for Native AOT : r/dotnet - Reddit, https://www.reddit.com/r/dotnet/comments/1q5oi7x/mewui_a_lightweight_net_ui_library_for_native_aot/
5. Shipping a GUI Without the .NET Runtime: 2 Months with MewUI, a Cross-Platform UI Framework : r/csharp - Reddit, https://www.reddit.com/r/csharp/comments/1rpxol3/shipping_a_gui_without_the_net_runtime_2_months/
6. VeryJokerJal/Jalium.UI: 一个全新面向未来的 UI 框架 - GitHub, https://github.com/VeryJokerJal/Jalium.UI
7. Youngjae Song al6uiz - GitHub, https://github.com/al6uiz
8. Jalium.UI 26.10.3 on NuGet - Libraries.io, https://libraries.io/nuget/Jalium.UI
9. VeryJokerJal/Jalium-UI-Gallery: A UI framework built from ... - GitHub, https://github.com/VeryJokerJal/Jalium-UI-Gallery
10. SupperJal - NuGet Gallery, https://www.nuget.org/profiles/SupperJal
11. Jalium.UI.Core 26.10.3 on NuGet - Libraries.io, https://libraries.io/nuget/Jalium.UI.Core
12. SoundFlow 1.0.1 - NuGet, https://www.nuget.org/packages/SoundFlow/1.0.1
13. SoundFlow 1.1.0 - NuGet, https://www.nuget.org/packages/SoundFlow/1.1.0
14. aprillz/MewUI: A cross-platform and lightweight, code-first .NET GUI framework aimed at NativeAOT. - GitHub, https://github.com/aprillz/MewUI
15. aprillz/DisplayBlackout.MewUI: A MewUI port of the Display Blackout. - GitHub, https://github.com/aprillz/DisplayBlackout.MewUI