Typora 里面图片放多了就奇卡无比

ummm 可能是因为图片控件用的是 RGB 图片，这种是不能压缩的。

你看 JPG 虽然小，但你用 width * height * 3 看看需要多少字节才能存下来？
压缩图片没法直接显示在屏幕上，需要解压成像素点的。

如果你开发过桌面应用你就也能明白了。系统是不可能让它“显式一张 JPG 图片”。你必须先把图片载入进来，像素点解码出来，然后给系统它才能显示。

我觉得就是这个原因。你看虽然你一屏显示的图片有限，但是你总不应该图片划过去了就删除内存对象，划回来了再重新解码 jpg 吧？那这种时候就不是内存占用的问题，是滑动起来一卡一卡的。一个页面上的所有图片驻留在内存里，这个做法还是比较合理的做法呀。除非一开始就打算了要显示一堆图片，针对性优化的。。。（比如长 word 的显示就应该优化了，但是 typora 一个 markdown 文档，人家也没想过这种硬核应用场景）

@ipwx 大佬牛逼，又学到了新知识

我并不同意，比如 firefox，我经常开几十个标签页，不乏图片很多的网站，但是也没有出现过这种情况。

很可能是 electron 的锅。

不是图片的问题，typora 字多了也卡

@delectate 优化过了吧。毕竟 firefox / chrome 都是一堆人开发，typora 只有一个人开发。

其实真的想要去优化大量图片的显示，肯定是有办法的。时间换空间，就好像我上面说的，想办法图片需要显示的时候再解压呗。再比如 Google snappy compression，压缩比不错速度又快（ 1GB/s 级别的），拿来压缩裸图片二进制数据流肯定是行的。哪怕是直接每次显示图片都重新从磁盘读，优化的不好可能会卡，但是优化好了也不见得多卡。

图片可以预先扫一遍获得 height width 信息，内存里面只存图片的大小和源，排版过程中计算高度只用信息不用图片对象，想必也能搞定。Chrome / firefox 可能确实有各种复杂的优化在，但是 typora 就算用了 electron / webkkit 也不见得把这些功能都用上了呗。

跟图片没什么关系，应该是 typroa 没对大页面做优化，一股脑把所有内容都丢给浏览器 build，慢是当然的

@hst001 不过说真的，有些东西真不容易计算高度。比如公式，多行公式之类的。。。

Markdown 除了 typora 之外全都不能用的主要原因，就是图片、公式多了，左右同步滚动的高度计算就是 shit 。也就行内混合的模式能支撑这种复杂的应用了。前段时间好像还有人在开发行内混合的 markdown 编辑器（ js 控件），milkdown 的，等一波看看后续发展。

可能在真实滚动所有 DOM （

@ipwx 像这种编辑器可以按块来划分，节点不能做深度嵌套，每个块在内容变动时 build 一次然后缓存尺寸，基本上可以应付大多数情况了，反正尽量不要深度嵌套，嵌套一深就不好对付

@hst001 总是能做的，但这就复杂了。。。

typora 看上去就没做这种程度的优化，都丢给下层了。

@ipwx 看来 Word 还是有很多学问可以研究

插个眼，我 typora 也卡，我怀疑是我 15 年 mbp 性能不行的锅。

可以来用 notion,如果不是用卡片笔记的话
notion enhancer 常驻后台 不会有卡的问题

字多了也卡

@ipwx 解析本地的图片和图床上的图片连接对比在占用内存方面 有啥区别嘛

我之前用 eletron+vue+elementui，写个一个非常简单的看漫画程序，本地滚动加载几十张图好像也没有卡顿。
会不会是 typora 需要渲染 markdown 所造成的性能问题

@duck2 如果都是载入内存，那应该没有吧 2333

很简单，将你的 markdown 用 vscode 打开试试，看还卡不卡。vscode 是我用过最舒服的 markdown 编辑器…… 你不一定需要 Typora 这种所见即所得的功能，实际上它编辑起来比较麻烦

@AItsuki vscode 可以打开侧边栏预览的，也是所见所得

用图床吧，本地放图片的话，你的 markdown 笔记怎么在各个设备之间同步。

奇卡无比 你用的是 base64 ？