我只用 Linux 所以只能提个思路，这个功能在 linux 异常简单。

现代桌面的窗口管理器的渲染逻辑是基本一致的，就是分配给应用程序一个矩形空间，由应用程序决定窗体内部的内容，然后窗口管理器（合成器）负责将其和标题栏部分合成起来。换个说法，标题栏不是应用程序决定的。

为了支持特定形态的窗体，一般桌面的窗口管理器也会提供一个叫 client side decoration 的机制，这样窗体相关的部分也交由应用程序负责。可以参考 https://en.wikipedia.org/wiki/Client-side_decoration

所以要实现这个功能一方面需要窗口管理器支持，另一方面要程序自身去适配 csd 机制。


如果只是单纯实现录屏的时候不含窗体，计算好坐标裁剪一下应该没问题。

不负责任的猜测，可能是百度统计被投毒了，文章截图里的几个受影响站点，外链 js 的交集就是 hm.baidu.com 域名下的 hm.js 文件。

楼上看 id 就知道靠谱。

网络这个领域一定要先有市场需求才有岗位需求，由于相关技术往往和硬件以及架构强绑定，离开了这个环境这些技术就没有用武之地了。

如果你真的想学，DPDK 建议往 ebpf 方向走，RDMA 往分布式存储方向走。

9950x 是基本频率 4.3 然后 Boost 最高到 5.7 ，如果你能接受降低到 4.3 ，有个简单的方法是用 amd-pstate 调度，在执行特定任务的时候限制在 4.3 ，执行完之后再切换回来。

参考 https://docs.kernel.org/admin-guide/pm/amd-pstate.html

```
To manipulate the boost attribute, users can write a value of 0 to disable the boost or 1 to enable it, for the respective CPU using the sysfs path /sys/devices/system/cpu/cpuX/cpufreq/boost, where X represents the CPU number.
```

我不确定是否能限制到 4.7 ，这要看 amd-pstate 是否支持。一个曲线救国的思路是写个假负载的程序然后绑定到 8~16 个核心上，让 cpu 误认为是全核心任务从而降低频率。

另外现在 amd 的 smp 调度还是有问题的，相关的内核补丁不确定能否赶上 6.12 的合并窗口。这一系列补丁主要是调度让单核心的任务跑在体质最好的核心上的。

@moyuman #13

平滑滚动是靠视觉残留形成的错觉，所以平滑滚动光标很容易做，但是平滑滚动内容本身是很难的。

由于终端里的内容基本不存在关联性，平滑滚动这个事情在不牺牲速度的前提下我个人认为不可行。

@adoal #16

OSC 52 确实是非常好的，终端里也不区分本地和远程。

当然我觉得这事属于历史问题，特别是 linux 环境。clipboard 是个桌面层面的实现，x11/wayland 还不一样，所以 vim 与系统剪贴板的交互是比较低效的 ipc ，而且需要编译期增加支持。理论上如果把 * 寄存器与系统寄存器关联也可以，但 vim 的设计 delete 会和 yank 同样使用 * 寄存器，这就导致按一下 x 也会触发一次 ipc ，一方面造成卡顿，另一方面用户也不想删除的内容进系统剪贴板。

我推荐 foot https://codeberg.org/dnkl/foot 另外这个作者其他项目也都非常好。


设计哲学层面我不是很认可 kitty/alacritty 的路线，恰好这个话题我在之前的讨论 zed 编辑器的帖子里提到过 https://v2ex.com/t/1056672 可以做参考。

foot 的作者也有专门写过文章论述 https://codeberg.org/dnkl/foot/wiki/Performance


除开渲染层面，foot 的作者同时维护 fcft 一个 rasterization 的库，这个库对于字符的处理我认为是目前最好的，foot 的字符显示就是基于 fcft 。

还有 foot 对于 OSC/escape sequence 的支持非常标准化，很方便做定制或者与其他应用交互。

我没有搜到 chromium 关于“机器码”相关的代码，而且常理上这个设计也很不合理。

我更倾向于认为是与 PAM 相关的原因导致的。登录凭证比如 cookies 这些是加密存储的，而 chromium 的加密密钥是存储各个平台的 keyring 的，mac/win/linux 都一样。Linux 环境解锁 keyring 与 PAM 相关，一般是登录桌面的同时解锁。

升级 bios 或者某些行为可能会导致 PAM 策略下 keyring 未能正常解锁。

至于是不是符合 Go 哲学的问题，我看不出这样做的意义。正常使用接口就可以了。

我有两个想法：

- 编译时方案，可以交给外部 preprocessor 当作模板来处理，后续代码生成之后再用 Go 编译，当然这个外部工具也可以用 go 写。目前来看基本上都要用特定的模板写法，而不是 Go 代码。

- 运行时方案，理论上这个需求和 hot reloading 应该差不多，对于 JIT 来说是比较好实现的，对于 Go 应该比较难。像 C 没有 runtime 是可以做到的，如果 Go 要实现类似的功能我估计需要魔改 runtime 才行。

我觉得需要重新描述一下，区分依赖注入和依赖注入框架。对 Go 来说，依赖注入几乎无处不在，但没有使用任何依赖注入框架的必要。

一时半会想不到特别合适的开源项目，我就尝试描述一下做法。正文里提到了依赖注入的两个场景，一个是被动初始化，另一个是单元测试。这两个都可以用接口 Interface 来完成，方法也是一样的。

标准库里有非常多传递实例的写法，比如传一个 *http.Client 这样。如果需要多个不同组件按照特定顺序初始化，可以直接用 struct embedding 把各个实例封装起来，然后就可以传递 struct 了。

因为我的组里有很多其他背景的开发者转型而来，对于传递 struct 的做法不认可，主要的理由是他们都有要初始化几十个依赖的经历。我对此的观点是，某个组件依赖几十个其他组件这件事本身就有问题，即便是真的有很多依赖，也只是依赖其中非常小的功能而非全部。我个人认为造成这种结果的原因是用基于 class 实现的继承去套用 Go ，而 Go 的做法是完全不实现继承功能，通过组合来抽象 OO 。

第二个需求单元测试需要对代码做调整，或者说对编程思路做调整。之前我在别的 Go 语言讨论帖子里反复引用过 Accept interfaces 这个说法，如果将调用方的代码依赖从实例改成接口，就可以非常简单地实现 mocking 来做单元测试。

因为调用方无须关心调用的是哪个实例，只要这个实例实现了特定的接口即可。将调用方的方法改写为接收接口，就可以用任意的实现来 mocking 对应的功能。

如果把接口当作继承来用，那自然就会觉得依赖是个复杂的事情，因为这个接口会越来越大，最终变成了模块之间的强耦合。实际上 Go 的思维里，接口越小越好，这里的思想是组合而非继承。一个非常小的接口是很容易 mocking 的。

另外如果观察一下 github 上 Go 的 DI/mocking 相关的项目也能发现一个趋势，相比其他语言这两种框架几乎都不流行。因为真的没有必要。不过反过来说，接口就是依赖注入。

技术层面窗口透明是合成器（ compositor ）的功能，应用自己并不能决定自己是否透明。或者换个思路，窗口合成器提供给应用一个抽象的渲染区域，这个区域出现在屏幕的什么地方，以多少透明度显示都是要窗口合成器控制的。

所以需要一个能控制窗口合成器行为的应用，插件起到了告诉这个应用把什么颜色当作透明色的作用。楼上 issue 链接里的插件就是这样。

frida-trace 看调用栈。

@shika #26

balance-rr 还有 tlb/alb 都不需要特定交换机支持，具体可以看 linux bonding 的文档。

但这个行为确实与交换机有关，当启用 balance-rr 的时候，在交换机看来多个端口对应设备的 MAC 地址在反复切换，交换机会有异常的表现。一般来说管理功能越高级的越可能出问题，傻瓜型的往往没有影响。

@porrt8 #22

没有关系，多链路的数据包也可以经过多网卡发送。多线程的情况下可以在不支持 rr 平衡模式的时候提供更好的带宽利用率，只是每个线程都无法超过单个网卡的最大带宽。

OP 描述的现象的实质与单链路和多链路没有关系，我这里简单解释一下，就以 OP 的环境为例，L2 交换机没有端口聚合的功能。

L2 交换机的工作原理是根据 MAC 将数据包发送到特定的物理端口上，物理端口对应设备的 MAC 是通过记忆或者 arp 协议来更新的。L2 链路聚合会使聚合的 NIC 设备共享相同的 MAC 。

设想客户端 MacBook 通过 smb 协议访问 Win/Linux 资源，这是个单链路的请求，到达交换机端口的时候，不同交换机可能有不同处理方式，不管怎么样，都只会通过一个口到达 Win/Linux 。

由于 Win 不支持 round robin 的平衡模式，所以返回数据一样只会走聚合链路中的一个。这是常说的单链路无法超过单一接口最大速率的情况。Linux bonding 的区别在于，返回数据（包）会轮流经由两个网卡发送，所以可以同时利用两个 NIC 的带宽。当这些数据包到达交换机的时候，又会被交换到客户端的那一个端口上。

能够实现这个效果的原理就在于 linux bonding balance-rr 这个实现。其他的负载平衡方式主要看 hash 参数，也有些自适应的模式能达到类似效果。更底层的原因是 linux 网络栈是内核实现，来源不同的包只要具有相同的元组就可以被内核转交给应用程序正常处理，而应用程序构造的数据包交由内核之后，经由什么途径发出与应用程序无关。

这个实现对交换机没有要求，如果交换机可以对两个端口做聚合会更好一些，这样就不需要反复更新 MAC 与端口的绑定。可能存在的问题是乱序，即顺序包经由两个 NIC 到达交换机时先后顺序错乱了。双 NIC 聚合可能还好，数量越多 rr 模式越可能产生乱序。


PS

上面说得可能有些抽象，如果有 socket 编程经验可能更容易理解一些。

关键点是网络栈是内核实现，协议/IP/端口这些都是属于内核的，而不是属于某个应用的，同样也不属于某个网络设备。应用只能通过 bind 之类的方法获得 IP 端口的使用权，内核收到的数据包，把内部应用层的部分交给应用程序。应用程序处理完毕后，发出的数据包实际还要回内核，由内核包装上外层协议并完成路由（一般说的四表五链），最终到达网络设备 NIC 的时候，再做 L2 层封装上 MAC 等等发送出去。

所以本质上应用层面上的单链路是否经由物理层面的单通道发送是不相关的两件事，正因为这种架构上的解耦，最终才能够实现单链路带宽翻倍的效果，同时还不需要特定的交换机支持。

eBPF ftw!

赞一个！

妙哉！

@yuan1028 #22

我一样很少用到，过去几年里都是如此。你可以看 #24 的回复，我跟你的观点是一致的，动态扩容是实例层面的事情，go 应用单体不应该考虑。这里讨论的是真正存在压力的生产环境。

性能指标这方面，还是要具体情况具体分析。我是极其反对单纯以 cpu 或内存占用作为性能指标的，除非它是真正的瓶颈。笼统地说我一般会跑一下火焰图和计时任务，观察一下可能的热点或者瓶颈在哪里，只有确认了瓶颈存在才会考虑优化。网络编程这个领域，多数时候加钱（ cpu 和内存）比加人工更有效。

具体到并发相关的参数，考虑一般有限资源环境中的调度问题，调度行为一定会产生损耗，根据特定的业务场景，追求低延迟就看前 5%的耗时，追求高吞吐就看 95% 的完成时间。看统计分布比看单一指标更有意义。