1957115 - add a more targeted WPT for the color-rendering-glitch that we hit with pseudo-rendering-invalidation.html

Status: RESOLVED WONTFIX

(Core :: CSS Transitions and Animations, task)

Description

[Daniel Holbert [:dholbert]]

bug 1839326 is about a view transitions WPT test (pseudo-rendering-invalidation.html) that hits a fuzzy failure on some platforms, with us rendering the color darkseagreen with slightly-wrong color-channel values (due to a rounding error at some level possibly).

I can reproduce the test failure locally with a substantially more targeted WPT. Filing this bug to add such a WPT as a more targeted test for this rendering issue, since pseudo-rendering-invalidation.html is really focused on pseudo-element behavior and might conceivably change to stop triggering this color rendering glitch.

Comment 1

[Daniel Holbert [:dholbert]]

(whoops, I forgot to adjust the component in the new-bug form. Fixing now; sorry for bugspam, audio/video folks. :) )

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: WIP: Bug 1957115: Add a more targeted test for a view-transition color-channel-rounding bug that we seem to hit on some platforms. r?boris

This is a narrower version of the shared WPT
'pseudo-rendering-invalidation.html', which is sufficient to reproduce the
color-channel off-by-one fuzzy failures that we get on some platforms with
that test.

I'm spinning this off as a targeted test so that we can be sure to have
test coverage for that color-channel issue, even if the original WPT happens to
change in a way that makes it stop reproducing there.

Comment 3

[Daniel Holbert [:dholbert]]

I've attached the narrowed test that repro's the issue pretty reliably for me locally (it repro's at least 50% of the time in my enable-debug/disable-optimize build).

So far I haven't managed to make this test repro the issue with this narrowed test on Try, so it's possible the race conditions work out a bit differently there; not sure.

I was able to catch this in rr and submit it to pernosco, though.

Here's the pernosco recording:
https://pernos.co/debug/O3GizwHF-BQeYde3wfrHXA/index.html#f{m[DZbL,AA_,t[AmA,AdQt_,f{e[DZbJ,BKw_,s{acpFcQAAA,bGg,uM02K,oM1A2___/

In this recording, the test runs twice (via --repeat-until-unexpected). The first time, it passes; and then it runs again and fails. This^ link is seeked to where we print the log line to report the failure -- FAIL, expected PASS [...] Found 10000 pixels different, maximum difference per channel 1

Comment 4

[Daniel Holbert [:dholbert]]

OK - in looking at pernosco, I think the reason for the test-failure isn't really a fixable bug, and I think there is a test-fix that we can justifiably land for this in bug 1839326.

What I observe in the pernosco trace is that we end up rendering two superimposed images, for the old and new snapshot. Both of them have a nsDisplayImage and a nsDisplayOpacity, with the nsDisplayOpacity::mOpacity having values nearly 1.0 and 0 but not quite.

The "old" snapshot has mOpacity 0.9999108910560608
The "new" snapshot has mOpacity 0.00008912435441743582

I think their nsDisplayImage display items are both just snapshots of the page (since the page isn't changing), so we're rendering two superimposed partially-transparent versions of the page with these^ opacities, which we're cross-fading between, over a duration given as the animation-duration in the testcase.

When these actually get drawn, per the note on https://www.w3.org/TR/css-view-transitions-1/#setup-transition-pseudo-elements-algorithm , view transitions images are supposed to be composited with mix-blend-mode: plus-lighter so that 'the blending of identical pixels from the old and new images results in the same color value as those pixels, and achieves a “correct” cross-fade'. However, I'm betting [have not fully confirmed] that in this case our ~0-opacity image is so faint as to have ~zero effect on the output; whereas the 0.9999-opacity-image has its math math works out such that the 0.9999 opacity brings us just below a rounding threshold, so that we floor to the lower color-channel-value.

In any case: I think we can avoid the issue by using a longer animation-duration so that we end up with interpolated opacity values that are much closer to 1 and 0. That makes it much harder to get floating point errors causing rounding issues like this.

Given all of the above, I'm less concerned with actually landing this test (since the bug is not user perceptible and has a reasonable explanation and is not obviously fixable); and I'd suggest that we propose to increase the animation-duration in pseudo-rendering-invalidation.html.

Comment 5

[Daniel Holbert [:dholbert]]

I'm calling this WONTFIX and I dropped some comments in https://phabricator.services.mozilla.com/D243377#8406551 with a suggested change for how to properly (I think) work around this color-channel subtlety.