Iced-rs项目在Wayland下CPU占用过高问题分析与解决

问题背景

在使用iced-rs框架开发GUI应用时，开发者发现当应用运行在Wayland显示服务器协议下时，会出现异常高的CPU占用率。具体表现为：

1. 在Wayland环境下运行简单的"Hello World"示例时，CPU占用率高达170%
2. 同样的示例在X11环境下运行时，CPU占用率接近0%
3. 使用wgpu的hello_triangle示例时，CPU占用率也接近0%

问题排查过程

初步分析

通过WAYLAND_DEBUG环境变量获取调试日志，发现系统不断重复以下Wayland协议调用：

[3481583.554] {Display Queue} wl_display#1.delete_id(66)
[3481583.557] wl_callback#66.done(146143)
[3481583.565]  -> wl_display#1.sync(new id wl_callback#66)

这表明系统在进行大量的wl_display.sync调用，导致事件循环不断被唤醒。

深入调查

通过gdb调试，发现调用栈指向了AMD Vulkan驱动(amdvlk64.so)：

#4  wl_display_roundtrip_queue (display=0x55555759c1c0, queue=0x555557bba8c0) at ../wayland-1.23.1/src/wayland-client.c:1440
#5  0x00007fff877eb802 in ?? () from /usr/lib/amdvlk64.so

这表明问题出在AMD Vulkan驱动不断调用wl_display.sync，导致：

1. 驱动调用wl_display.sync
2. 合成器回复(写入socket)
3. 所有监听该文件描述符的组件(winit、smithay-clipboard等)被唤醒
4. winit读取到Ok(0)(表示其队列中没有新事件)后返回睡眠
5. 驱动再次调用wl_display.sync
6. 循环重复

解决方案

将图形驱动从AMDVLK切换为RADV(Mesa的AMD Vulkan驱动)后，问题得到解决。原因在于：

1. RADV使用Mesa的WSI(Window System Integration)实现
2. RADV不会无故调用wl_display.sync
3. RADV只在确实需要同步操作(如绘图、表面创建等)时才进行同步

技术要点

1. Wayland同步机制：wl_display.sync用于确保操作完成，通常用于注册表获取等关键操作
2. 驱动行为差异：不同Vulkan驱动在Wayland环境下的实现方式不同
3. 事件循环唤醒：不当的同步调用会导致事件循环频繁唤醒，增加CPU负载

建议

对于使用iced-rs框架在Linux Wayland环境下开发的开发者：

1. 优先使用RADV驱动而非AMDVLK驱动
2. 在遇到类似高CPU占用问题时，可通过WAYLAND_DEBUG环境变量获取调试信息
3. 关注图形驱动与Wayland协议的兼容性问题

总结

这个问题展示了Linux图形栈中不同组件交互时可能出现的微妙问题。通过深入分析Wayland协议调用和驱动行为，最终定位并解决了高CPU占用问题。这也提醒开发者，在跨平台GUI开发中，需要关注底层图形栈的差异和兼容性问题。