#js #web React direct GPU

https://github.com/remorses/gpuix

GPUI is an immediate-mode UI framework — it rebuilds the entire element tree every frame. Instead of fighting this, GPUIX embraces it:
React reconciler detects a state change and queues host mutations (createElement, setStyle, appendChild, etc.)
applyBatch() validates and applies the complete commit to the Rust RetainedTree

值得注意的是，实现了一组基本的CSS https://github.com/remorses/gpuix#supported-styles

但文档一眼AI，甚至有点管理不住模块化的感觉（毕竟GPUI套娃），感觉最近看AI文档都有点ptsd了

你说不好吧，也不行，因为许多人写不到这么细，但是还是感觉很草蛋

#ai探讨

GPUI 的本质：
GPUI（Zed 编辑器用的底层）是 Rust 下受 Flutter/SwiftUI 启发的声明式渲染器。所谓 immediate-mode element tree，是它每帧通过 render closure 重新生成一套极其轻量的 Rust struct 视图树，依赖 Rust 零成本抽象、编译期静态检查与紧凑内存布局来保证极致的高帧率（60~120fps）。

React Reconciler 的本质： React 的 react-reconciler 是彻头彻尾的保留模式（Retained-mode）增量对比器。它做 Fiber diff、生成 patch mutation 操作指令流（appendChild, commitUpdate 等）。

所以他不得不在 Rust 侧人肉实现一个微型的 DOM 树（RetainedTree）作为中介缓存。 整个流程变成了：这是在 Rust 内存里造了一层 Shadow DOM，然后每次重新把这颗 DOM 树转译成 GPUI 的元素。

每次 React 提交 setStyle，Rust 端得把 CSS 解析成 GPUI 具体的样式属性。 而不是 Tailwind/SwiftUI：.flex().gap_2().text_color(...)

一旦把事件（onClick, onHover）暴露给 React，就意味着要跨 FFI 往 JS 引擎派发事件

--
哦，我大概理解为Rust是直接把 Gtk/Qt式的 children 放在func body里的，通过一个loop unroll做的ImGui，其实是真正的0开销
div()
.flex()
.child(text("hello"))
.child(button("click"))
不过， 不使用dirtyRect节省重绘在一些屏幕上没问题吗？

在现代硬件架构下，很多时候全屏重绘（Full Redraw）反而比 CPU 精细计算 Dirty Rect 跑得更快、吞吐更稳。
新时代（Metal / Vulkan / WebGPU / Apple Silicon）： 在 4K/5K 屏幕上，哪怕 60/120Hz，统一内存（Unified Memory）或现代独立显卡每秒几百 GB/s 的带宽根本不在乎你多填几个色块。

GPUI 是 Tile-based / Batching 渲染，不是纯暴力贴图

很多人对 Immediate UI 有个误解，以为它像 3D 游戏一样只要开着就在疯狂死循环 120fps 刷 GPU。 实际上 GPUI 是事件驱动的即时模式（Event-driven Immediate）：
屏幕静止、没有鼠标移动、没有光标闪烁、没有数据更新时：0 fps，完全休眠，GPU 功耗为 0。

听起来很有趣。虽然ImGui被许多人认为是现代、高完成度快速响应复杂UI的模式，优化上面也是有些区别的吧，比如文字渲染和dpi的问题、性能耗电，以及是否对前沿App普遍更好

底层直接接入系统的原生排版或工业级 HarfBuzz / FreeType / CoreText。动态 LRU 纹理图集： 只有屏幕上真正出现的文字字形（Glyph）才会被光栅化并写入 GPU Atlas。动态 LRU 纹理图集： 只有屏幕上真正出现的文字字形（Glyph）才会被光栅化并写入 GPU Atlas。

你需要手动写 ImGuiListClipper，在代码层人肉告诉引擎：“当前视口只看得到第 50 到第 80 行，请只执行这 30 次循环”。 GPUI 虚拟化滚动内置（Virtualization）： 深度结合视口，虽然外观像 Immediate，但其内部对长列表和富文本实现了类似 Retained 的分块测量缓存

ImGui 证明了“单向流与消除复杂状态树”的可行性，而现代 Rust 应用框架则是把排版、渲染管线、色彩管理和矢量栅格化的工业标准

看来还是不要陷入Rust狂热，reflow和复杂外语的渲染确实是大问题，不过GUI毕竟不是浏览器，这方面可以做两套运行时按页换。 onDPIchange 这个我是没见过，毕竟电脑屏幕不是游戏，每天有人场上换装备接着打
我说的按页换是指实现层，不是节点图层……

感觉dpi的问题被夸大了。 我是完全没有遇到，即便有两个屏幕时。感觉用两个屏幕像是差生文具多，为什么不搞个截图糊弄一下，状态管理问题才值得解决
好了，现在BeOS时代的矢量图又回来了，只不过以一种侵入式的方法，把本来重绘bitmap的问题变成了编程问题

🤔 叽里咕噜说什么呢？ 我看，我终于找到为啥读起来一眼AI了

这tm是拿人人手搓Office或Renderer的标准要求一个微信计算器小程序啊

（Event-driven Immediate）：
屏幕静止、没有鼠标移动、没有光标闪烁、没有数据更新时：0 fps，完全休眠，GPU 功耗为 0。

学到一个新知识： ImGui只是不做子区更新，不是60fps烧电池，但也不要以为显卡程序更先进了，文本+reflow上游戏UI没法看

Rust通过<T>单态嵌入和DSL直接把HTML弄成字节码的模式也很有趣, Container<Tuple<Text, Button>>，看起来那样比ts2c成功多了，如果用于常用App的话会跟手不少。过去很多人幻想“把 TypeScript 静态编译成 C/C++ 来替代 Electron”。

#vibe 感觉现在真是每个星期都能找到值得学习的项目，但是又没有在做什么。

这两天写了个Vim #lua 配置

正好把之前的 https://t.me/dsuse/22874 说法 实现了一下…… 我的天，还真是 iframe in Vim 😅

虽然整体设计不方便交流，但小细节确实非常搞笑（高效）。 唉，我是否也该变成楼上那种monorepo干三年的大佬呢？

还是要保持码场自由人的传统呢？ ……

#code init.lua 120行， 实现了KDE下往vim里内嵌窗口

象征性开源一下，没有什么功能。 有些感叹， 4天前说的概念，这不就用上了……

做了个C/C++窗体热重载功能， 对GTK挺好的（简直良心，比Web世界快多了），Qt的话官方IDE编译性能也不咋地，没有QML重载就做不出效果

当然也支持pyqt/gobj的，只是要写cpp exec()。

我觉得Vim应该也就拿来写个c系，py js 应该不搭的吧…… 但反过来，哪怕是G/Q的官方IDE也不如LazyVim

#ai探讨 https://chat.librechat.ai/share/gM26LMXRmBmB1MOtYI02Q

聊了关于此Vim配置（真的只是配置？？） 和vibe带来的问题。 AIGC的毛病不止影响“业余狂吹”，也会影响我们……

——他们都在说AI取代古法编程，可是我这一和你说，就发现有很多误会，根本做不到免费升IQ。 当然，Moonbit的张宏波认为AIGC对系统编程也是有帮助的（虽然他实际上没有多用）。 理解一门编程语言，和说它，是两回事

#linux #ai

托瓦兹表示，最终修复只涉及把错误的 round_up () 改为 round_down () 😅😅😅。不过，定位过程远比修复代码复杂：他累计添加 24 个补丁，用于逐步增加调试信息，并启动内核 18 次，才锁定内存破坏的具体原因。

托瓦兹表示在本次调试过程中，AI 承担添加调试代码和分析输出结果等大量重复工作。在调用处理过程中，AI 多次得出该问题无法解决的结论，不过在托瓦兹的多次协调指导下，不断推进让 AI 生成新的调试工具

https://t.me/im_RORIRI/34538

所以，比起有些人热爱 Code Agents ，我坚定不移的跟随 Alan Kay ，交互介质才是未来。我认为 User Interaction 和 Dev. Common Sense 的问题仍然没有得到解决

UX可不是一个节点/图层/事件入口而已，它就像typec和全面屏一样， 很多人误以为【即时连接】就是简单肤浅的，这种想法让它们认为更强大和复杂的 Agent 才是人机接口的未来。

💭 Bret Victor 所展示的那种【反AI】，不是因为他不知道老虎机能以多快的速度，实现哪些【网上早有，你没发现】的practice：比如仿照《植物大战僵尸》什么的

而是一种对【语言之死】的无视。 智能是有【载体】的，就像编程语言有高亮和Tab键，就像一本小说有【目录】和【主线人物】，一部视频游戏有【玩法/操作】和【数百个脚本】，而这些差异经常被力大砖飞派完全忽视， 就像F12常常被当作是Web世界的【常理】和空气

你不是在用Codex用LLM，而是在用【老极客的文字和行号】，这才是真正的模态，而且这不是最好的用法。

再过五年，我们看今天的Agent，可能就像看罗马数字或诺基亚上的26键一样，会觉得它fancy的动画和高度集成只是在掩盖罗马数字的晦涩。

SataEric
Claude 定价里那个“20x”真的很误导人。

$100 方案说是 Pro 额度的 5 倍，$200 方案说是 Pro 额度的 20 倍。听起来你好像能获得 4 倍用量。

但那个 20x 只适用于 5 小时使用窗口。每周限额其实基本只是 $100 方案的 2 倍。

我花了太多时间在互联网和 Reddit 上翻找才搞清楚。他们本来可以直接写明限额，而不是拿“20x”来宣传。

光是这点就能省下我几个小时的一头雾水。

推特上一群所谓KOL一样的大佬们的大脑一直都在升级，从mac升级到加密货币再升级到AI，就好比装在他们大脑位置里的是一个跟着潮流走，可拆卸的模块，今天拿出来一个新的把旧的换掉，就获得了新的姿势。

可惜了，他们唯独缺乏一个属于自己的大脑。

很多人讨论 MiniMax H3 Max

可以称之为 faster than real time 的视频生成模型：5 秒视频 3 秒出片，声音画面同一次生成。视频被创作出来的速度，超过了它被观看的速度，这意味着视频内容的「制作」和「实时性」被AI完成了双重平价化。

目前AI视频的内容还更多的在制作网剧， Startup宣发小视频领域发光发热。
刚好看到他提供免费使用接口了，不用注册每天可以生成五段5秒768p视频

#ai 感觉这个在中推的讨论度还不够高，但下一个全新产品形态的机会确实出现了。
https://x.com/whereisvivien/status/2093946583125803329?s=46

#py #ai Bub is a tiny runtime for agents that live alongside people.

~200 lines of core code. Hooks reshape every turn stage. Tapes record every decision. Channels adapt to any surface — CLI, Telegram, or your own.

一个用只增Tape管理AI记忆的IM2LLM服务

bub 是我们在超级全家桶和纯 vibe 定制中间寻找的一个解决方案
——Frost Ming

- 难道说我在既有 Tape as a Service 的情况下，只要100行代码，就能让我的 agent 接入 bub ，然后让 IM 群聊复用现有的数据吗 ？！
- 给 @bubdotbuild 加上了企业微信的 Channel，现在上班摸鱼有新搭子了😉
- 一个类似于 Cloud Code 一样的通用 Agent 框架……使用 bub 作为一个 build block 构建你自己的 agent 产品、服务你的业务，而不是学习复杂的概念然后无从下手。 https://bub.build/

#tg Tape 事件流服务/上文过滤是骨架，那么 Hooks 就是赋予骨架灵魂的定制代码。

可以用钩子来净化文本、进行意图识别、或者从数据库查询额外信息。

Channel 是一个适配器层，它定义了如何接收来自特定平台（如命令行、Telegram、微信、Web 页面）的消息，以及如何将 Agent 的回复发送回该平台。

曾经设想过一种tgbot api 的类似CGI的运行模式，但当时的设计仅仅能让多个Chatbot拉群免重复配置，非常贫瘠。 SCP-079 那样通过private广播监听微服务，又过度设计。

如果bub里能多Agent共享内存，或许就不一样了，比如，可以搞bridge bot，可以用Web调试tg上的群，等等。非AI应用如数据统计也没问题呢

以前想给不同的bot设置一个Webhook实例，但是场景非常有限。 如果是不同的聊天软件，甚至支持Tape类型化记录的话，确实是很 fast forward 的方案，想想就比一堆Bot克隆人有趣

#os 其实，这种单向数据流、多模块并行的设计，就是 Alan Kay 的 Actor。 这种模式最初在Etoys里用于一个支持碰撞转向的玩具小车（可以独立的暂停，通过色点重叠触发计算事件）

通过这种方法实现多函数合作，更加动态类型，而且每个组件存储与事件更独立，非常适合人机接口类App。让人十分意外的是， Linux io_uring SHM就是这样的模式

#ce https://t.me/im_RORIRI/34611

我们自己搞的那套 Haxe Reflaxe 插件可以直接把 Haxe 的子集转换成 Dart Kotlin Rust TypeScript Swift 没有 FFI 税，Macro 的魔法 ˊ_>ˋ

目前已经做了数组迭代函数自动展开成 for 循环，也是很好玩的特性。

我准备做的阴间事情：用 Haxe 做 JS 下的 0 GC 优化。大的数据全都用二进制存储，提取数据全都用函数去 DataArray 里面查表，数值取出来往下传参的全用 Macro 换成 Data Chunk 和起始指针，只有出了编译器系统才实例化成正经 Object，在优化范围内流转全都不创建 Object，编译器会根据不同上下文直接给函数展开成多态。可以说是一种非常邪门的优化了，这东西主要是为了治单一信源下大量小 object 光速创建造成的 GC 压力，不创建就没有 GC。这都是 Macro 的奇迹才能做出来的东西 ˊ_>ˋ

https://try.haxe.org/#15fdD633
https://try.haxe.org/#Add701b8 🤔生成了俩傻逼Haxe入门

感觉这个在线编辑功能不咋样

#TIL -gc boehm 扫描程序的堆和栈，寻找看起来像指针的值，这能奏效？？ dlopen即可用的级别？

简直像直接为C支持了深拷贝一样，虽然通过mmap匹配的方法，指针对齐后有确定特征，但这也太免费了

你完全不需要知道client用了什么对象树，不需要支持Map,List, Cell vars，甚至连栈都不一定需要分出来？ 😨

当 autofree 搞不定时（比如复杂的对象图、循环引用）：开发者可以轻松切换到 -gc boehm，程序立刻就能在“大部分情况”下正确工作，就像py的 import gc ，就像valgrind和perf，免费获得了无源码的GC……

#ai 喜报： https://chat.librechat.ai/ 支持 Steering Messages 了

喜欢发长文的人可以分段后直接批量发送了

ps. 没想到他们给 Send Queue 起了这样的名字。 按我看，这个功能ChatUI第一天就应该做，比什么 /prompt 角色扮演重要多了

花大量精力去卷各种浮夸的 Agent 工作流或 Prompt 广场，反而把最基础的“人机输入交互”当成了理所当然的单行道。 “挤牙膏”式等待。

比起 Gemini 好久还支持的 Edit，LC早就可以替换或 fork 对话

⚡️ 是对方发送时队列中的消息，可以逐条编辑

💭 是我的错觉吗？ 从来没听人提过消息队列的需求，好像他们的AI是5秒秒回的，或者大众完全不会让AI精细阅读一整篇文章？ 对我而言第一天就需要【保留---截断的文本，不断点发送按钮】的逻辑