Walked back the manual-interpolation + CABasicAnimation+presentationLayer
attempts at lockstep keyboard inset. Both leave a visible frame of lag
because the lockstep problem is structural, not implementation-detail:
- GL renderbuffer content is baked at presentRenderbuffer() time.
- The CoreAnimation compositor can interpolate the *position* of a
CALayer per-vsync but cannot reach into our renderbuffer's pixels.
- The GPU pipeline (CADisplayLink → command build → present →
compositor → display) is 2-3 frames deep on iOS GLES, so even
`targetTimestamp`-based prediction is one to two frames short.
The architectural escape that doesn't move the GL view (rejected for
edge cases) is to give CoreAnimation a renderable handle it can sync
on. That means **Metal**:
- CAMetalLayer + MTLDrawable.presentAtTime(_:) caps the pipeline at
exactly one frame.
- With targetTimestamp prediction + curve-accurate keyboard math,
our drawable lands at the same vsync as UIKit's keyboard.
- Renderer modernization (Metal/Vulkan/WebGPU per platform) was on
the roadmap anyway; lockstep is the forcing function.
This commit keeps the keyboard observer + show/hide_keyboard wiring
intact and SNAPS keyboard_height when the observer fires. Behavior:
the chess board doesn't shift during the keyboard animation; it shifts
in one step when the observer fires. Less smooth than the broken
attempt but honest.
Plan for the Metal port (next):
- library/modules/gpu/{metal,vulkan,webgpu}.sx + a `GPU` protocol
analogous to Platform.
- Port modules/ui/renderer.sx shaders from GLSL to MSL.
- SxGLView becomes SxMetalView; CAEAGLLayer becomes CAMetalLayer.
- Lockstep falls out of MTLDrawable.presentAtTime(targetTimestamp).
2ff24e29cc