Opacity reftest failures when using softpipe: a 1px high line with 1 RGBA level difference

If GTK's build-time tests are run with GALLIUM_DRIVER=softpipe, some recently-added reftests fail. This is non-architecture-specific (it happens on x86_64 just as much as any other architecture), but particularly affects CPU architectures where Mesa's llvmpipe is broken (like mips64el) or unavailable (like riscv64, because llvmpipe uses a deprecated JIT interface for which LLVM is not accepting new architecture support).

The cairo rendering seems to match the reference every time, it's only GL where it can differ.

The autobuilders used to build distribution packages generally do not have access to a GPU, so they will usually have to fall back to software rendering of some sort, either llvmpipe or softpipe.

In Debian, we're working around this by allowing small rendering differences in the affected tests (GSK opacity-overdraw and GTK opacity). I tried submitting a MR a while ago to add the infrastructure to be able to do this (!3195 (closed)) but it was rejected.

GSK opacity-overdraw

Expected:

Actual:

Emphasized difference (it seems to be the line where the outside top of the red square meets the inside of the blue square):

# 20 (out of 900) pixels differ from reference by up to 1 levels

In the flipped/repeated/rotated renderings (not attached here, our infrastructure to exfiltrate diffs via autobuilder logs doesn't yet know about the variant renderings) the difference is in 21, 80 or 39 pixels respectively, but again only by up to 1 level per RGBA channel per pixel.

GTK opacity

Expected:

Actual:

Emphasized difference:

# 40 (out of 1800) pixels differ from reference by up to 1 levels