Update roborazzi to v1.75.0 - #1933
Open
renovate[bot] wants to merge 1 commit into
Open
renovate[bot] wants to merge 1 commit into
renovate[bot] wants to merge 1 commit into
Conversation
Contributor
Preview ChangesNote Compared against the baseline rendered from Changed (1 variant(s) across 1 function(s))
Unchanged (141 function(s), 280 variant(s))
|
renovate
Bot
force-pushed
the
renovate/roborazzi
branch
from
September 24, 2026 16:38
b88f330 to
69d177c
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
1.74.0→1.75.01.74.0→1.75.01.74.0→1.75.01.74.0→1.75.0Release Notes
takahirom/roborazzi (io.github.takahirom.roborazzi:roborazzi-junit-rule)
v1.75.0Compare Source
Preview screenshots are 1.6x faster, and up to 3.7x with the new
renderScaleTwo 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.
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
BasicTextFieldnow 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:
renderScaletrades fidelity for up to 3.7x (experimental)renderScalescales 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 } }renderScale1.0(default)0.51.0 / 3.0The
vs 1.74.0column is what you actually see when you upgrade and set the value in the same step.Three things to weigh before lowering it:
dpandspfollow 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.0.5to1/3cuts the pixels by more than half but buys only 1.2x more speed, because what remains is per-preview setup rather than rendering.0.5is 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.
ComposePreviewTester.Optionsgained arenderScaleparameter. Source-compatible, but the JVM signatures of its constructor andcopychanged, so a customComposePreviewTestershipped as a prebuilt artifact has to be recompiled against 1.75.0. Testers built from source with the rest of your project need nothing.Thanks to @sergio-sastre for reviewing this before it shipped and for suggesting an option to change the render scale per preview, which is what
@RoboComposePreviewOptions(renderScale = ...)does.This is
@ExperimentalRoborazziApi: the name and behaviour may still change, and we are looking for feedback on it. If you try it, tell us what you measured and whether the trade-off worked for your suite in #929.How these numbers were measured
From this repository's own
sample-generate-preview-testsmodule (26 Compose previews). Its sources and Gradle configuration are byte-identical between tag1.74.0and 1.75.0, so every configuration renders exactly the same previews.:sample-generate-preview-tests:recordRoborazziDebugonly — record, no comparemaxParallelForks = 1(the Gradle default)<testcase time>, with the first preview of each run excluded: it absorbs JVM, Robolectric and Compose initialisation (2.9-3.2 s in every configuration, ranges overlapping) and would otherwise hide the per-preview cost entirelyWhole-task times, for reference — these include Gradle and JVM start-up and are not comparable to the per-preview figures above:
renderScale = 1.0renderScale = 0.5renderScale = 1.0 / 3.0Also: UI tree dumps no longer change on their own between runs
A semantics value whose type does not override
toString()was written to the dump asandroidx.compose.foundation.VerticalScrollableClipShape@5fb48f31. The hash half is the JVM's identity hash, so it changed on every run and the dump differed even when nothing in the UI did. Only the class name is recorded now, and whether the defaulttoString()is in play is decided by reflection, so a customtoString()that merely looks like the default is left alone. Dumps holding such a value change once, the next time you record. This is the same trap #911 fixed forCustomAccessibilityAction, reached through a different type.Thanks to @ryancfogarty for finding and fixing it in #924.
What's Changed
New Contributors
Full Changelog: takahirom/roborazzi@1.74.0...1.75.0
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR was generated by Mend Renovate. View the repository job log.