chrome gpu：
-
main bitmap， cached bitmap， decode bitmap
-
Index color， 不直接存颜色 bit，二是调色板的地址
-
加速只用于 video 和 graphcis
-
Render
a.instance SkImage and cached skim age
b. Raster skimage => index color => bitmapImage, allocated memory
c.GPU bitmap => texture, with cached: GPU 内存空间，只读的，可绘制单位（包含宽、高，色彩通道等） ，
、由 GPU 专门的硬件 texture 处理
P1:渲染：
node => renderObject > renderLayer（css transform） => Graphcis Layer，（1 对多，合成过程）
rO=>rL:
1.root
2.css postion
3.transparent
4.canvas
5.gif/video
r=>G 怎么分层：
- CSS filter, transform, z-index
2.CSS animation
3.video, gif(decoding)
- Canvas, acc 2d context
P2.Compositer:
Where Gpu in
将 gl tree 中 bitmap 转为 texture，vbuffer
Immutable
- 区分 data 和 time，容易回溯
- 复用内存
- 节省 CPU，不存在复杂的 diff，无非自底向上构建新树，原先的都在
- 时间旅行，基于 1，放进一个数组管理 5.并发安全，不用额外添加锁
- FP
- 实践： a. shouldComponentUpdate，只渲染更新部分，传统 deepcopy 耗时
如何进行文档懒加载？
（获取显示区域）=> 长文本提高性能 => 文档如同构建 DOM 树，递归的， 这个过程没办法优化，但我们可以优化文档本身的内容，把他拆分成连续的部分。 问题：HTML 字符形式无法切分，因为它是对称。 我们退一步，将文档进行 Change 化，就可以很简单的划分了，同时可以根据操作计算对应文档的长度。 语言是如何 parser 的 反观代码编辑： 每一行为一个单位，很容易判断当前那些行在区域内
为什么长文本模式下性能显著提升 1.cke 长文本局限: 自动保存 没有这个逻辑判断：因为做不了，富文本设计的 dom 操作远比代码编辑器复杂 2.codemirror 怎么做： parser 只渲染当前 view 窗口内 有一套逻辑用于判断文档是否活跃，用于停止整个 parser 流程