zjchina.net

Drogon · ROS 2 · 独立开发笔记

ADR-00072026-10-03

tidewatch 行情交易页率先吃自绘内核，图表专用渲染优先、通用组件延后

拍板：zj

背景

ADR-0005 已拍板「自绘为尊、web 走浏览器渲染兜底」，并据此把 dioxus-blitz 证伪、 落地为独立 wgpu 内核 zjchina-render。该内核已转正为一个领域无关的最小 L0 绘图库： instanced 静态几何一次性上传 + 每帧仅写 16B 投影 uniform，bin/candle.rs 基准以 5 万蜡烛（10 万 instanced 图元）+ 中文字形标签在 macOS/Metal 稳定 120 FPS。

但内核当前仍是「能画」的绘图能力，没有接入任何真实页面——它与「真实交易页面 渲染」之间缺一条明确的落地路线。核对现状后发现一个矛盾：tidewatch 桌面端 tw-desktop 依然走 dioxus 0.8.0-alpha.1 的 desktop 特性（本质是 wry/WKWebView 壳，恰是 0005 证伪的路径），尚未消费 zjchina-render。用户的诉求是：把自绘内核 应用到真实交易页面（tidewatch 行情/模拟交易），并要一份分阶段计划清单——这需要 时间，不能一步到位，须先定路线与顺序。

选项

  • A. 在 zjchina 内直接做通用 UI 组件渲染层（≈ 重写 blitz）。 一步到位但周期 最长、风险最高，与 0005「不复现 Dioxus 组件渲染」直接冲突，且要在通用排版（flex/ 文本换行/可点击控件）这条最深的沟里一次灌满，违背「先在真实场景验证成熟」的既定 路线。
  • B. 先做 web 商城页自绘。 违反 0005「web 永不自绘」——对外站点靠 SEO、零安装、 零 JS 首屏吃饭，自绘会全面倒退；中舰落地页 /mall/zhongjian 继续走 DOM+SSR 即可。
  • C. 以 tidewatch 行情/模拟交易页为第一个真实场景，分阶段接入 zjchina-render， 图表专用渲染优先、通用组件渲染延后，验证成熟后回迁 zjchina 真机端（采纳）。

证据

  • 0005 修订记录（2026-09-28）：blitz 出局（crates.io 未发布、pre-alpha，且 desktop/mobile 实际映射 wry/WKWebView）；独立 wgpu 内核 spike 可行；转正为 zjchina-render（独立 workspace，不并入根 members）。
  • 2026-09-29 三层叙事：内核刻意领域无关、不垄断事件循环，宿主在自身 ApplicationHandler 内调用 render()——这为 tidewatch 渐进嵌入预留了正确切口。
  • 本次现状核对（2026-10-03）：
    • zjchina-render/src/ 九模块齐全且带单测：primitive（Lines/Rects/Mesh 三原语 + Aabb2）、scene（revision 脏标记）、renderer（quad/line 双管线 + 视口裁剪）、 text（fontdue 中文字形 512×512 R8 atlas）、camera（16B uniform）、axis （nice_ticks）、input（滚轮缩放/拖拽平移）、app（单窗口宿主）、fps。
    • tidewatch/crates/tw-desktop/Cargo.toml 仍为 dioxus … features=["desktop"] （WebView 壳），未引 zjchina-render——自绘内核尚未接入真实桌面端。
    • tw-datafeed 已具备真实行情源（reqwest + rusqlite + 签名/编码），数据侧不是 缺口，缺的是「数据 → 场景 → 自绘」的桥。
  • 领域友好性：K 线/成交量/指标叠画天然映射到内核既有原语（Mesh 蜡烛体、 Lines 网格、Rects 副图、nice_ticks 刻度、text 中文标签），是「图表专用 渲染」的最低验证成本场景，不必先啃通用排版引擎。

拍板

拍板者 zj：tidewatch 行情/模拟交易页是自绘内核的第一个真实场景；走「图表专用 渲染优先、通用组件渲染延后」的分阶段路线，每阶段独立可验证、可回滚，验证成熟后 再回迁 zjchina 服务真机设备端（工厂大屏/工业平板/HMI，对应 LET_TIME_SEE Phase 5.3）。 tw-desktop 现存的 dioxus desktop 壳作为过渡对照保留、不立即拆除；自绘内核以独立 消费者渐进接入，成熟后接管桌面真机端渲染。web 商城页（中舰落地页）不涉自绘，继续 DOM+SSR。AI 协作者（TRAE）参与现状盘点与选项对比，拍板权属作者。日期：2026-10-03。

分阶段落地清单（每步独立可验证）

阶段 A  真实数据接入    tw-datafeed 行情 → scene 增量更新，实测 revision 脏标记的
                      增量上传是否真省带宽（candle.rs 静态数据 → 真行情流的第一次缝合）
阶段 B  交互闭环        十字光标 / tooltip / 缩放拖拽映射真实时间轴与价格轴
                      （当前 input 是 demo 级 pan/zoom）
阶段 C  图表完备        K 线 + 成交量副图 + 指标叠加，复用 Lines/Rects/nice_ticks/text
阶段 D  交易控件        下单面板 / 挂单列表的布局与排版（自绘最难关）
阶段 E  翻译层定策      拍板「图表专用渲染」还是升级「通用 UI 组件渲染」，不被
                      「重写 blitz」诱惑提前越界
阶段 F  回迁 zjchina    接真机大屏/HMI，服务 5.3 智能工厂轨道

阶段 A 是明确的下一个动作；其余阶段按 A 的实测结果滚动细化，不预付实现。

阶段进度与定策记录

  • 阶段 B/C/D 已完成（2026-10-03）：真实行情接入（tw-datafeed → scene 增量更新）、 十字光标/tooltip/缩放拖拽映射真实轴、K 线+成交量副图+MA5/10/20 指标叠画、交易 控件（下单面板/挂单列表的屏幕空间 overlay 布局 + 命中检测 + 点击反馈）均已落地并 冒烟验证稳定。
  • 阶段 E 定策（2026-10-03）：阶段 D 交易控件是「图表专用渲染」的边界试金石， 实测划出能力分界——
    • 可达（图表专用渲染内生能力）：屏幕空间 overlay（面板钉死、不随图漂移）、固定 坐标布局、矩形命中 + 手写 if-else、双 render pass 叠加——交易面板四件套全靠 这些即可排版，无需通用排版引擎。
    • 够不到（需通用 UI 组件渲染才补）：文本度量/居中、IME 文本输入、flex 流式布局、 滚动列表、组件树/事件冒泡。交易盘口的输入框/滚动挂单列表恰落在这条边外。
    • 拍板：维持「图表专用渲染」，不升级为「通用 UI 组件渲染」，更不「重写 blitz」。 自绘内核只揽行情图表/HUD 这类专用渲染；交易面板等通用控件与可输入表单交由 dioxus + web 浏览器兜底（0005 的既定分工），内核与 web 在真机端按场景各管一段， 不在通用排版这条最深的沟里灌水。tw-desktop dioxus shell 延续作为通用 UI 载体。
  • 阶段 F 回迁 zjchina（下一步）：图表专用渲染验证成熟后，接真机大屏/HMI， 服务 5.3 智能工厂轨道；通用控件侧由浏览器兜底渲染。
← 返回决策日志