不使用 Web 引擎绘制出真正玻璃效果的搜索卡片

查找是编辑器中经常使用的功能。但因为它一直运行得很好，所以很久都没有动过它。

mote 的查找窗口也是如此。它一直占据两行，即使先在文档中选中单词再打开，搜索词输入框也依然是空的。

三款应用给出了相同的答案

在着手修改之前，我们在 Typora、MarkText 和 Obsidian 中打开同一份文档，调出查找与替换并截了图。Notion 则通过公开的帮助文档进行了确认。把它们整理成表格后，共同点就很明显了。

查找都是从一行开始的。替换只在需要时才展开。选中的单词会直接进入搜索词输入框。把匹配数量放在输入框内，以及通过箭头在各个匹配项之间移动，这些做法也大多相同。

mote 也决定遵循这一流程。

默认界面缩减为一行。可以通过左侧按钮或 Ctrl+H 打开替换。如果选中的句子只有一行且不超过 200 个字符，就会自动填入搜索词。

没有匹配结果时，会显示“无结果”，而不是数字 0。输入框还会出现红色边框。这样就能立即确认究竟是拼写错误，还是文档中确实没有这个词。

只是减少了一行，正文就能显示得更多了。第一个搜索结果被卡片遮住的情况也减少了。

查找的使用频率远高于替换。如果把偶尔才用的功能一直展开，就会让频繁进行的操作每次都付出代价。

我们并没有把所有东西都改得和其他编辑器一样。悬浮在右上角的卡片和选项按钮都保留了原样。考察其他产品并不是为了照搬，而是为了区分哪些是用户熟悉的方式，哪些是 mote 自己的选择。

卡片下方的文字会真正变模糊

查找卡片看起来像玻璃。这并不只是一个视觉效果。卡片下方的正文确实会经过模糊处理后重新绘制。

最初，我们决定在 Linux 上完全去掉模糊效果。GTK 的渲染器不具备对同级组件后方表面进行采样的功能。再加上每次滚动文档时背景都会发生变化，因此必须逐帧重新计算。我们判断，比起漂亮的画面，流畅的画面更重要。

解决办法不是让卡片自身产生模糊，而是由编辑器直接绘制模糊后的画面。

编辑器绘制文档时，会把卡片覆盖的部分再绘制一次。第二次绘制时应用 18 px 的模糊效果，卡片只在其上叠加一层淡淡的色调。

重新绘制的只有卡片下方实际可见的那些行，而且这项工作发生在本来就要绘制的帧内。空闲状态下安排的帧数依然是 0。

页眉也是同样的方式。滚动文档时，标题会进入页眉下方并自然地变得模糊。由于清晰画面和模糊画面是在同一时刻绘制的，所以不会彼此错位。

玻璃边缘没有使用阴影，而是加了一条 1 px 的边框。因为在白色文档上，仅靠阴影很难分辨边缘。卡片与窗口右侧之间则留出了 24 px 的空隙，以便看见阴影。

我们没有添加出现动画。按下 Ctrl+F 的人已经有了想查找的内容。即便是短暂的演出，在这个时候也会变成等待。卡片会在按下按键的瞬间打开，并且从第一帧开始就呈现出玻璃般的效果。

被遗漏的搜索结果也重新找回来了

缩减界面之后，那些搜索结果没有正确显示的地方也显现了出来。

表格内的结果没有着色。在阅读模式下，突出显示的位置会发生错位。而在行内代码和荧光标记内部，原有的背景色会遮住搜索标记。

每个问题的原因都不一样。

在表格内，需要为每个单元格分别计算位置。在阅读模式下，需要重新校准被隐藏符号的位置。而对于带有背景色的文字，则需要先绘制搜索标记。

我们修正了位置的计算方式和颜色的绘制顺序，解决了这三个问题。

搜索结果以黄色显示。只有当前正在查看的结果显示为橙色。屏幕、PDF 和 HTML 中都使用相同的颜色。

文字颜色没有改变。因为荧光笔不是涂在文字上方，而是位于纸张与文字之间的颜色。

玻璃是有成本的

在查找卡片保持打开的状态下滚动时，模糊效果会针对每一帧重新计算。虽然只重新绘制卡片下方的部分，但成本并不会消失。

所以我们不会叠加很多层玻璃。只在页眉、侧边栏和当前打开的一张卡片上使用。

玻璃不是装饰材料，而是一项必须在性能范围内分配使用的预算。

让查找窗口变得更漂亮和让它变得更轻量，看起来似乎是两件相反的事。但最后剩下的问题只有一个。

这个画面应当在什么时候重新绘制？