Status Update
Comments
vi...@google.com <vi...@google.com>
je...@google.com <je...@google.com> #2
ta...@gmail.com <ta...@gmail.com> #3
Ideally there would be two thresholds we could customize:
- Pixel difference threshold, i.e how much any given pixel can change before it's considered different from the target pixel.
- Total difference threshold, i.e how much of the total screenshot can be different from the target
In my situation, the ideal settings (and what I currently use on other tools/platforms) is ~1% pixel difference threshold to ignore text rendering and anti-aliasing differences that occur across hardware and a 0% total difference threshold so that any change more significant than that is flagged immediately.
Using a single total difference threshold to ignore aliasing is unideal, because on screenshots with text this value can end up being very large to account for every possible pixel that could receive different aliasing. So large that other actually important differences may sneak by undetected, e.g. the height or color of a divider line.
hu...@google.com <hu...@google.com> #4
I like the idea of having multiple thresholds. Could you please explain option 2 (total diff) in more detail?
ta...@gmail.com <ta...@gmail.com> #5
Option 2 (total difference) is the percentage of the image that is allowed to be 'different' from the reference image. For example, if the reference image is 10x10 pixels, a 5% threshold would allow the test to pass even if up to 5 pixels do not match the reference. In my opinion, this is the least useful threshold option, even though most other screenshot testing tools have it, as it's the most straightforward threshold to implement. I avoid using this kind of threshold because it doesn't scale well with large screenshots. If I'm taking a screenshot of an entire screen of my app, say 1080x1920, even a small threshold of 0.5% allows for over 10,000 pixels to not match the reference. This means that it's possible the test won't catch important changes like the color of a border, a change of font, or potentially even a small icon disappearing.
What I find to be a more useful option is configuring when any given pixel is considered different from the reference pixel. For example, if I have a screenshot of an black circle on a white background, my laptop (an Apple Silicon MacBook) will anti-alias the image slightly differently than a colleague's Windows desktop or the Linux instance running my tests for CI. Even though to the human eye the image is identical, it will fail due to the minor differences in the gray pixels used to anti-alias the edge of the circle. In this situation, I don't care if a pixel that was #9A9A9A is now #9B9B9B; they're essentially identical, and I'd want the test to ignore that difference.
Trying to work around this kind of issue with option 2 isn't ideal. Larger screenshots have more anti-aliasing, which necessitates a larger total difference threshold to ignore the larger number of imperceptible differences, which in turn just increases the potential for a meaningful change to not be detected.
hu...@google.com <hu...@google.com> #6
huge shoutout to jrodbx for amazing writeup of the problem and suggested solution
maybe the same can be applied here, or shared with the papparazi lib
ta...@gmail.com <ta...@gmail.com> #8
but the problem with rendering of colors is still there, not sure will it be dealt with in this ticket via smart diffing, or the other
meaning if you render the previews on different machines and you get the color space problem, you will need almost ~0,5f (50% ?) threshold to let the tests pass
see attached images of a button as example
in another example of color mismatch
composable code color hex:
0xFF003EB0
reference image hex from (CI ubuntu x86_64 GNU/Linux machine)
FF2B2D30
actual image hex(mbpro M1 Max)
FF003EB0
(please note this does not mean macbook is always the correct one, as we have multiple identical mac machines, some of the devs get different colors rendered, I am not sure where the differences stem from, maybe some internal dependency of the library)
hu...@google.com <hu...@google.com> #9
Diff threshold feature is enabled since alpha06 version. This does not solve the platform related rendering differences. Tracking that as a separate issue and closing this
Description
```
A problem occurred evaluating project ':app-java'.
> Failed to apply plugin [id 'com.android.internal.version-check']
> Minimum supported Gradle version is 5.6.4. Current version is 5.4.1. If using the gradle wrapper, try editing the distributionUrl in /Users/sdane/dev/others/pickle/sample/gradle/wrapper/gradle-wrapper.properties to gradle-5.6.4-all.zip
```
After this, I want to run `./gradlew wrapper --gradle-version=5.6.4 --distribution-type=all` in oder to update. Since the check is on configuration time, `wrapper` task just fails with the same reason.
Would it be possible to skip this check when `wrapper` task is the one that is running?