Skip to main content

Frame Boundary & Picture Replay

One of the most important renderer decisions in current Kanvas is where a Compose frame is considered complete.

The implementation is in SkikoFrameTransformer.java.

Modern Skiko behavior​

Modern Skiko separates recording from final presentation:

update(...)
   │
   └─ records Compose drawing into a Picture
                         │
                         ▼
                    draw(Canvas)
                         │
                         └─ replays the complete Picture

Kanvas therefore prefers draw(Canvas) as the frame boundary when that method exists.

Why not capture only update(...)?

The recording phase is not necessarily the final visual payload. In modern Skiko, the complete recorded picture is replayed later. Treating the earlier recording method as the final frame can miss the actual content that reaches presentation.

Fallback behavior​

The transformer inspects the target class before rewriting it.

  • if a supported draw(Canvas) boundary exists, Kanvas uses picture-replay mode
  • otherwise, if a supported update(...) boundary exists, Kanvas uses the recording fallback
  • if neither exists, the transform is marked failed and the audit log records the incompatibility

That is an intentional compatibility strategy: prefer the semantically correct modern boundary without deleting support for older/unusual layouts.

Transform failure is meaningful

If neither supported boundary exists, Kanvas does not pretend the runtime is compatible. The failure is recorded because presenting a partially understood frame would be worse than refusing takeover.

Why inspect method signatures at runtime?​

Kanvas crosses a private implementation boundary in Skiko. Method names and layouts can move between versions.

The transformer therefore checks actual bytecode structure instead of assuming a version string alone proves compatibility.

Source: