chore(deps): bump roborazzi from 1.70.0 to 1.75.0

[dependabot]

Bumps roborazzi from 1.70.0 to 1.75.0.
Updates io.github.takahirom.roborazzi:roborazzi from 1.70.0 to 1.75.0

Release notes

Sourced from io.github.takahirom.roborazzi:roborazzi's releases.

1.75.0

Preview screenshots are 1.6x faster, and up to 3.7x with the new renderScale

Two changes to generated preview tests, plus a determinism fix for UI tree dumps.

1. Generated preview tests are 1.6x faster per preview — nothing to configure

Generated Compose Preview tests no longer recreate the Activity and Compose configuration for every preview.

	per preview	goldens
1.74.0	153.5 ms	736 KB
1.75.0	96.0 ms	736 KB

The same change can alter what you record

Reusing that setup meant fixing the order it runs in. Generated Android preview tests used to launch their Activity first and apply the preview's device, night mode and font scale afterwards, so startup saw the wrong environment. The configuration is now applied before the Activity is launched (#932), along with two related lifecycle fixes: cached Compose rules are released after the test (#930) and the Compose configuration, including fontScale, is restored after the capture scenario closes (#931).

This is a fix, but it can change what you record. Anything whose rendering depends on when composition starts relative to Activity startup may come out differently. In this repository's 26-preview sample, one screenshot changed: a focused BasicTextField now draws its text cursor, which matches what Android Studio's preview shows. Re-record and review your goldens after upgrading; previews with focused text fields, or with work started at composition time, are the ones to look at.

2. New: renderScale trades fidelity for up to 3.7x (experimental)

renderScale scales rendering density while each preview's logical dp dimensions stay the same, so the layout is unchanged and only the pixel count drops.

roborazzi {
  generateComposePreviewRobolectricTests {
    enable = true
    packages = listOf("com.example.previews")
    renderScale = 0.5
  }
}

renderScale	per preview	vs default scale	vs 1.74.0	pixels recorded	goldens
1.0 (default)	96.0 ms	—	1.60x faster	100%	736 KB
0.5	49.0 ms	1.96x faster	3.13x faster	25%	292 KB
1.0 / 3.0	41.0 ms	2.34x faster	3.74x faster	11%	184 KB

The vs 1.74.0 column is what you actually see when you upgrade and set the value in the same step.

Three things to weigh before lowering it:

• Your screenshots hold fewer pixels, so a small visual regression can fall below the resolution you record at. Re-record your goldens when you change this value.
• Anything sized in raw pixels does not scale with it. dp and sp follow the density and keep their proportions, but a value given in pixels — drawLine(..., strokeWidth = 1f), a px offset — stays that many pixels in a smaller image, so it comes out relatively thicker and in a different place. Previews built on px measurements are not simply a smaller version of the original.
• Returns fall off quickly. Going from 0.5 to 1/3 cuts the pixels by more than half but buys only 1.2x more speed, because what remains is per-preview setup rather than rendering. 0.5 is a reasonable starting point.

Only the rendering shrinks: launching the Activity, composing and writing the file cost the same at any scale. A preview that renders a lot of pixels can nearly halve its time, while a small component is mostly setup and barely moves — in this repository's sample that setup floor is about 35 ms of the 96 ms. Measure before committing to a value.

... (truncated)

Commits

• c97214e 1.75.0
• 03fc7d8 Merge pull request #934 from takahirom/takahirom/per-preview-render-scale
• c269e49 Regenerate the preview support skill reference
• 320c740 Give renderScale its own section in the preview docs
• 820aef2 Lead the renderScale docs with the problem it solves
• 5a2ccc9 Document what renderScale buys and costs on the Gradle property
• 222ee24 Verify a preview that explicitly asks for the unscaled density
• 9e0a5a3 Point the renderScale mismatch message at effectiveRenderScale
• e4866f4 Record the render-scale expectation for custom Android testers
• b9e7452 Match the full parameter signature when resolving an overloaded preview
• Additional commits viewable in compare view

Updates io.github.takahirom.roborazzi:roborazzi-compose from 1.70.0 to 1.75.0

Release notes

Sourced from io.github.takahirom.roborazzi:roborazzi-compose's releases.

1.75.0

Preview screenshots are 1.6x faster, and up to 3.7x with the new renderScale

Two changes to generated preview tests, plus a determinism fix for UI tree dumps.

1. Generated preview tests are 1.6x faster per preview — nothing to configure

Generated Compose Preview tests no longer recreate the Activity and Compose configuration for every preview.

	per preview	goldens
1.74.0	153.5 ms	736 KB
1.75.0	96.0 ms	736 KB

The same change can alter what you record

Reusing that setup meant fixing the order it runs in. Generated Android preview tests used to launch their Activity first and apply the preview's device, night mode and font scale afterwards, so startup saw the wrong environment. The configuration is now applied before the Activity is launched (#932), along with two related lifecycle fixes: cached Compose rules are released after the test (#930) and the Compose configuration, including fontScale, is restored after the capture scenario closes (#931).

This is a fix, but it can change what you record. Anything whose rendering depends on when composition starts relative to Activity startup may come out differently. In this repository's 26-preview sample, one screenshot changed: a focused BasicTextField now draws its text cursor, which matches what Android Studio's preview shows. Re-record and review your goldens after upgrading; previews with focused text fields, or with work started at composition time, are the ones to look at.

2. New: renderScale trades fidelity for up to 3.7x (experimental)

renderScale scales rendering density while each preview's logical dp dimensions stay the same, so the layout is unchanged and only the pixel count drops.

roborazzi {
  generateComposePreviewRobolectricTests {
    enable = true
    packages = listOf("com.example.previews")
    renderScale = 0.5
  }
}

renderScale	per preview	vs default scale	vs 1.74.0	pixels recorded	goldens
1.0 (default)	96.0 ms	—	1.60x faster	100%	736 KB
0.5	49.0 ms	1.96x faster	3.13x faster	25%	292 KB
1.0 / 3.0	41.0 ms	2.34x faster	3.74x faster	11%	184 KB

The vs 1.74.0 column is what you actually see when you upgrade and set the value in the same step.

Three things to weigh before lowering it:

• Your screenshots hold fewer pixels, so a small visual regression can fall below the resolution you record at. Re-record your goldens when you change this value.
• Anything sized in raw pixels does not scale with it. dp and sp follow the density and keep their proportions, but a value given in pixels — drawLine(..., strokeWidth = 1f), a px offset — stays that many pixels in a smaller image, so it comes out relatively thicker and in a different place. Previews built on px measurements are not simply a smaller version of the original.
• Returns fall off quickly. Going from 0.5 to 1/3 cuts the pixels by more than half but buys only 1.2x more speed, because what remains is per-preview setup rather than rendering. 0.5 is a reasonable starting point.

Only the rendering shrinks: launching the Activity, composing and writing the file cost the same at any scale. A preview that renders a lot of pixels can nearly halve its time, while a small component is mostly setup and barely moves — in this repository's sample that setup floor is about 35 ms of the 96 ms. Measure before committing to a value.

... (truncated)

Commits

• c97214e 1.75.0
• 03fc7d8 Merge pull request #934 from takahirom/takahirom/per-preview-render-scale
• c269e49 Regenerate the preview support skill reference
• 320c740 Give renderScale its own section in the preview docs
• 820aef2 Lead the renderScale docs with the problem it solves
• 5a2ccc9 Document what renderScale buys and costs on the Gradle property
• 222ee24 Verify a preview that explicitly asks for the unscaled density
• 9e0a5a3 Point the renderScale mismatch message at effectiveRenderScale
• e4866f4 Record the render-scale expectation for custom Android testers
• b9e7452 Match the full parameter signature when resolving an overloaded preview
• Additional commits viewable in compare view

Updates io.github.takahirom.roborazzi from 1.70.0 to 1.75.0

Release notes

Sourced from io.github.takahirom.roborazzi's releases.

1.75.0

Preview screenshots are 1.6x faster, and up to 3.7x with the new renderScale

Two changes to generated preview tests, plus a determinism fix for UI tree dumps.

1. Generated preview tests are 1.6x faster per preview — nothing to configure

Generated Compose Preview tests no longer recreate the Activity and Compose configuration for every preview.

	per preview	goldens
1.74.0	153.5 ms	736 KB
1.75.0	96.0 ms	736 KB

The same change can alter what you record

Reusing that setup meant fixing the order it runs in. Generated Android preview tests used to launch their Activity first and apply the preview's device, night mode and font scale afterwards, so startup saw the wrong environment. The configuration is now applied before the Activity is launched (#932), along with two related lifecycle fixes: cached Compose rules are released after the test (#930) and the Compose configuration, including fontScale, is restored after the capture scenario closes (#931).

This is a fix, but it can change what you record. Anything whose rendering depends on when composition starts relative to Activity startup may come out differently. In this repository's 26-preview sample, one screenshot changed: a focused BasicTextField now draws its text cursor, which matches what Android Studio's preview shows. Re-record and review your goldens after upgrading; previews with focused text fields, or with work started at composition time, are the ones to look at.

2. New: renderScale trades fidelity for up to 3.7x (experimental)

renderScale scales rendering density while each preview's logical dp dimensions stay the same, so the layout is unchanged and only the pixel count drops.

roborazzi {
  generateComposePreviewRobolectricTests {
    enable = true
    packages = listOf("com.example.previews")
    renderScale = 0.5
  }
}

renderScale	per preview	vs default scale	vs 1.74.0	pixels recorded	goldens
1.0 (default)	96.0 ms	—	1.60x faster	100%	736 KB
0.5	49.0 ms	1.96x faster	3.13x faster	25%	292 KB
1.0 / 3.0	41.0 ms	2.34x faster	3.74x faster	11%	184 KB

The vs 1.74.0 column is what you actually see when you upgrade and set the value in the same step.

Three things to weigh before lowering it:

• Your screenshots hold fewer pixels, so a small visual regression can fall below the resolution you record at. Re-record your goldens when you change this value.
• Anything sized in raw pixels does not scale with it. dp and sp follow the density and keep their proportions, but a value given in pixels — drawLine(..., strokeWidth = 1f), a px offset — stays that many pixels in a smaller image, so it comes out relatively thicker and in a different place. Previews built on px measurements are not simply a smaller version of the original.
• Returns fall off quickly. Going from 0.5 to 1/3 cuts the pixels by more than half but buys only 1.2x more speed, because what remains is per-preview setup rather than rendering. 0.5 is a reasonable starting point.

Only the rendering shrinks: launching the Activity, composing and writing the file cost the same at any scale. A preview that renders a lot of pixels can nearly halve its time, while a small component is mostly setup and barely moves — in this repository's sample that setup floor is about 35 ms of the 96 ms. Measure before committing to a value.

... (truncated)

Commits

• c97214e 1.75.0
• 03fc7d8 Merge pull request #934 from takahirom/takahirom/per-preview-render-scale
• c269e49 Regenerate the preview support skill reference
• 320c740 Give renderScale its own section in the preview docs
• 820aef2 Lead the renderScale docs with the problem it solves
• 5a2ccc9 Document what renderScale buys and costs on the Gradle property
• 222ee24 Verify a preview that explicitly asks for the unscaled density
• 9e0a5a3 Point the renderScale mismatch message at effectiveRenderScale
• e4866f4 Record the render-scale expectation for custom Android testers
• b9e7452 Match the full parameter signature when resolving an overloaded preview
• Additional commits viewable in compare view

[maik-mursall]

@dependabot rebase

[maik-mursall]

@dependabot rebase