Speed up CropView rotation: GPU-resident source + per-generation content bake

[muukii]

Summary

Two performance fixes for slow CropView rotation, found and verified with on-device Instruments Time Profiler traces. Both are behind pixel-equivalence tests (the editing canvas renders black on the Simulator, so correctness is guarded via CIContext read-back, and the felt win was confirmed on device).

1. Make the editing source GPU-resident (adaptive bit depth)

The editing source was a CPU-backed CIImage(cgImage:), so Core Image re-uploaded its bitmap CPU→GPU on every canvas render. During rotation the viewport cache invalidates every frame, so the trace showed CIMetalTextureSetBytes / replaceRegion:withBytes: consuming ~40% of all main-thread time.

EditingSourcePreparation.makeGPUResidentSource uploads the oriented source into a persistent private MTLTexture once at load (background queue) and returns a texture-backed CIImage. The texture depth adapts to the source: rgba8Unorm for an 8-bit source (the common case — lossless, half the memory), rgba16Float for >8-bit / HDR.

This re-does what #297 removed, but avoids that PR's downsides (MTKTextureLoader 8-bit quantization / no 16-bit / y-flip) by rendering through a CIContext in the source's own color space — the CIContext.render(to:) / CIImage(mtlTexture:) round-trip is flip-free. EditingImageWarmUp is deleted (building the texture warms the pipeline).

2. Bake the local-effect layer once per generation

With the upload gone, the trace's remaining per-frame cost was Core Image re-evaluating the blur-heavy adjusted graph every frame (create_intermediate / GetSurfaceFromCache — IOSurface allocation under a barrier lock). The effect content is invariant during a gesture; only the viewport moves.

EditingCanvasContentBake.bake renders the adjusted layer into a capped (2560) texture once per render-images generation; the composite path resamples it per frame. The cache is invalidated only on setRenderImages / setViewportCachedSourceEnabled, never on viewport changes. base (global pointwise effects on the now-GPU-resident source) stays a live graph — cheap to re-evaluate, and not baking it halves the held texture memory.

Measured (device, normalized ms per wall-second)

Main-thread cost	before	after
Canvas draw (MTKView.draw)	102	26
CI graph eval (tile_node_graph)	70	3
IOSurface alloc + barrier lock	58	0
Per-frame source upload	(eliminated in step 1)	0

CA::Transaction::commit dropped 158 → 90. The new dominant rotation cost is UIKit layout (updateUIViewController → updateCropLayout), tracked as a follow-up.

Memory

Adaptive source depth + baking only adjusted keep the footprint bounded. For an 8-bit source: plain crop/rotate holds just the ~26MB source texture (≈ the pre-change CGImage footprint); a blur-mask gesture adds one ~52MB adjusted bake. The adjusted bake stays rgba16Float deliberately — it is the extended-linear-Display-P3 intermediate, where 8-bit linear bands and can't carry exposure overshoot / wide gamut.

Test plan

• xcodebuild -scheme BrightroomUI builds.
• EditingSourceTextureTests — texture-backed source is pixel-equivalent to CIImage(cgImage:).oriented() across 8 orientations × {8,16}-bit (16 cases).
• EditingCanvasContentBakeTests — bake is a faithful drop-in (offset extent, asymmetric content, within float tolerance; cap respected).
• Regression-green: ColorContract, CropSurfaceBlurRenderPath, CommittedMaskParametricParity, LocalAdjustmentRendering/MaskOrientation, EditingPreviewExportParity, MaskedPreviewExportScaleConsistency, RendererOrientation.
• Device re-trace to confirm keeping base un-baked did not re-introduce per-frame cost (expected fine — pointwise on a GPU texture).

Follow-ups (docs/editing-engine-todo.md item 7)

• UIKit per-frame layout during the angle drag is now the dominant rotation cost.
• Remaining bake-memory levers (resolution cap, confirmed-SDR formats) if needed.

🤖 Generated with Claude Code