树莓派LED矩阵街机项目如何在双进程间共享帧渲染资源

存在第三种更符合行业常规实现的方案：部署独立的专属渲染进程，所有硬件渲染相关的逻辑（LED矩阵库初始化、后台更新线程、vsync调度）全部收敛到该进程中，菜单、游戏均作为纯逻辑进程运行，仅通过IPC向渲染进程发送帧数据或渲染指令。
该方案的优势非常明显：

• 从根源上避免多进程争抢硬件资源的问题，不需要修改LED矩阵库的内部逻辑
• 完美适配你要求的渲染层解耦需求：仅需要替换渲染进程的实现，即可无缝切换到PC端GUI模拟运行，所有逻辑进程的代码不需要做任何修改
• 扩展性更强，后续新增其他需要渲染的业务进程时不需要调整现有架构

如果不采用第三种方案，两种现有方案中优先选择第二种：
第一种方案的弊端除了需要改库、扩展性差之外，切换进程时的资源销毁和重新初始化会带来不可控的闪屏风险，仅适合切换频率极低的极简场景使用。第二种方案的两次帧拷贝开销对你的使用场景可以完全忽略：常规RGB LED点阵单帧数据量仅几KB，就算跑满60帧每秒的带宽需求也远低于树莓派的IPC性能上限，实际使用中不会产生可感知的延迟。

由于vsync能力由LED矩阵库提供，仅持有库实例的父进程可以接收vsync信号，你可以按照如下逻辑实现同步：

1. 父进程在每次收到库的vsync回调时，通过IPC向当前处于活跃状态的子进程（游戏/菜单）发送帧同步通知
2. 子进程仅在收到帧同步通知后才开始计算下一帧内容，计算完成后将帧数据写入共享内存，再向父进程发送帧就绪通知
3. 父进程收到帧就绪通知后，将共享内存中的帧数据拷贝到LED矩阵库的原生framebuffer中，等待下一次vsync自动刷新输出

帧率管控逻辑完全由父进程侧实现即可：你可以将父进程的渲染上限设置为和LED屏的物理刷新率一致，超出上限的帧请求直接丢弃，子进程不需要单独做帧率控制，完全跟随父进程的同步信号输出即可，既不会出现画面撕裂，也不会产生多余的性能浪费。
不需要修改LED矩阵库的内部初始化逻辑把framebuffer放在共享内存，单独开辟一块和库framebuffer大小完全一致的共享内存空间即可，拷贝操作的开销完全可以忽略。

内容的提问来源于stack exchange，提问作者Benjamin