sceneReuse

Whether the run serves every capture from one shared scene instead of standing a scene up per fixture. On by default. Becomes the viddik.sceneReuse system property.

The default lives here, in the plugin, and not in the engine: the tasks this plugin registers run the generated screenshot tests and nothing else, which is exactly the condition a shared scene needs. captureComposable and ViddikEngine.verify called from your own test keep standing up a scene per capture, because there the plugin cannot know what else shares the JVM.

Standing a scene up is most of what a capture costs — an empty capture measured 11.7 ms against a median fixture's 12.1 ms — so sharing one takes a suite of same-sized fixtures from ~13 ms per capture to ~6 ms. The scene is reopened whenever the next fixture has a different canvas, because a Dialog centres itself in the window; a suite whose sizes alternate every fixture therefore gains nothing, and one whose fixtures share a size gains the most.

Two constraints come with it. The run must not contain other Compose tests that stand up a harness of their own — a shared scene cannot share a JVM with one, and the run fails with "the shared capture scene did not answer" rather than hanging; set this to false if your verification task runs such tests. And the fixtures are visited in size order rather than registry order, because the scene is reopened for each new canvas size.

Measured on a downstream suite of 748 fixtures: 71 s to 52 s on its own, and the goldens are identical either way — this repository's CI records its own suite through both paths on three operating systems and compares.