PhotoCraft复制写时（COW）稀疏瓦片技术揭秘：大画布为何内存占用只有1/3

PhotoCraft复制写时COW稀疏瓦片技术揭秘大画布为何内存占用只有1/3【免费下载链接】photocraftAn open-source, clean-room reimplementation of Adobe Photoshop in pure Rust项目地址: https://gitcode.com/gh_mirrors/pho/photocraftPhotoCraft 是一个用纯 Rust 编写的开源 Photoshop 重实现项目。它最核心的性能设计之一就是位于 crates/raster/src/lib.rs 的复制写时Copy-on-Write稀疏瓦片Sparse Tiles把画布切成 256×256 的小块只在有内容的地方分配内存复制画布只复制指针不复制像素。正是这套机制让超大画布的内存占用可以做到全量存储的约 1/3撤销Undo也因此变得极其廉价。稀疏瓦片不用的像素不占内存传统图像软件里一张画布就是一整块连续内存6000×4000 像素的 8 位 RGBA 文档光是空着就要吃掉96 MB。而 PhotoCraft 的画布是一个无限平面的 256×256 瓦片网格瓦片尺寸定义在 crates/geom/src/lib.rs没画到的瓦片根本不存在——读的时候按默认像素返回图层是透明蒙版是白色上面这张 6000×4000 的画布理论上需要 24×16 384 个瓦片每个瓦片 256 KB如果画面内容只覆盖 1/3 的画布其余透明实际分配的瓦片就少 2/3——96 MB 直接降到约 32 MB这就是1/3 内存的来源。关键 API 是Surface::tile_mut第一次写入某块瓦片时才分配内存读像素的read_pixel对缺失瓦片零开销。复制写时COW克隆画布 复制指针更巧妙的是每个瓦片都用 Rust 的Arc原子引用计数共享存储。于是克隆整个画布是 O(瓦片数) 的指针拷贝不复制任何像素字节谁要修改某块瓦片才复制那一块Arc::make_mut其他瓦片继续共享画满 4 个瓦片的图改 1 个像素后两份画布实际只有 1 块瓦片是独立的——单元测试copy_on_write_shares_untouched_tiles精确验证了这一点。还有一个瘦身收尾动作Surface::prune会把被擦回默认像素的瓦片直接释放配合content_bounds从瓦片外圈向内扫描快速算出内容边界——全画布选择时只扫描外圈瓦片而不是每个像素。撤销历史每一步都几乎免费这套瓦片直接决定了撤销功能的实现哲学crates/ops/src/lib.rs历史栈里存的是整文档快照听起来很费内存但因为瓦片共享一份快照只是几百个指针的拷贝连续做 50 步调整历史中 49 份快照与当前文档共享绝大部分瓦片只有真正被修改过的瓦片才计入内存内存预算按历史独占、未共享的像素字节结算History::held_bytes超预算时从最旧的快照开始淘汰最近一步永远保留同一机制还让后台任务导出、自动保存可以把瓦片借走再还回take_tiles/put_tiles主线程继续编辑也不冲突。这正是官方对它的总结——README 中的 Copy-on-write tiles 特性条目256² 稀疏瓦片让撤销很廉价让巨大的画布很轻盈。性能收益一览场景朴素方案PhotoCraft 瓦片方案6000×4000 空白 RGBA 画布96 MB≈ 0只有元数据内容占 1/3 画布96 MB≈ 32 MB记录一步撤销复制整张画布复制指针 改动瓦片读取空白区域遍历像素按默认像素填充跳过缺失瓦片延伸阅读瓦片表面完整实现crates/raster/src/lib.rs撤销历史与内存预算crates/ops/src/lib.rs瓦片常量与网格坐标crates/geom/src/lib.rs渲染管线如何按瓦片跳过空块book/src/architecture/rendering.md.pcraft 文件格式如何按内容寻址存储瓦片book/src/formats/pcraft.md简单说稀疏 没画的不占内存COW 没改的不复制内存。两个懒加在一起大画布编辑从内存灾难变成了几百个指针的小事——这也是 PhotoCraft 作为纯 Rust 图像处理引擎能在消费级硬件上流畅运行的关键原因之一。【免费下载链接】photocraftAn open-source, clean-room reimplementation of Adobe Photoshop in pure Rust项目地址: https://gitcode.com/gh_mirrors/pho/photocraft创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考