1760795 - Animated images may flicker white on Asus wifi "wave" animation (due to resetting animated background-color before resetting the animated width/height)

Status: NEW

(Core :: CSS Transitions and Animations, defect)

Description

[Alice0775 White]

Attachment: the image (for reference)

Steps to reproduce:

1. Open https://www.asus.com/Networking-IoT-Servers/WiFi-Routers/ASUS-Gaming-Routers/RT-AX82U/
2. Accept cookies if any
3. Scroll to Whole-Home Gaming
4. Watch the aniation

Actual results:
Animated images may flicker white

Expected Results:
No flicker on Chrome.

Comment 1

[Alice0775 White]

Screencast: https://www.youtube.com/watch?v=5FV_SidbVkk&t=3s

Comment 2

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4c53c4da7ece47da52974e38be6300c1212dc3e7&tochange=6128a351b7e7dc8b75f789a884948764a0f8e1e9

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

:hiro, since you are the author of the regressor, bug 1699890, could you take a look?
For more information, please visit auto_nag documentation.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

This is probably due to the background-color animation in question is running with width animation starting from 0 to 400%, thus at the moment of width:0 but we do create a background color display item to run the background-color animation on the compositor, thus something goes wrong because the item size is empty. No further idea without debugging.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: screencast

Comment 6

[Daniel Holbert [:dholbert]]

I've attached a screencast showing the flicker (it happens around 4 seconds into the screencast).

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: snippet of the screencast with the flash

Here's a screencast of me watching the crucial part of the formerly-attached screencast, in slow motion. This slow-motion version makes it a bit easier to see the moment where the flash happens.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: snapshot at the moment of the flash

When the flash happens, it's just the animating circles themselves briefly switching to be extremely-bright-white (they are much fainter in the frame before and frame after the flash).

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (warning, very flashy, might annoy photosensitive folks)

Here's a reduced testcase.

EXPECTED RESULTS:
You should never see red when viewing this animation. It only animates to red for the portion where the animated square is tiny enough to be fully covered up.

ACTUAL RESULTS:
I often see a flash of red when the rectangle hits its maximum size.

Notes:

• The animation is animating to a nearly-transparent color, but that transparency isn't necessary in order to trigger the bug; it just makes it easier to see.
• Comment 4 had a theory about this being related to the animated element having a 0px size; but I think this testcase disproves that theory, since here the element is always at least 100px by 100px.

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (should look static, but sometimes flashes red due to this bug)

Here's a simpler testcase.

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: testcase 3

Here's a testcase like testcase 2 where I've added a bunch of main-thread work to make the bug easier to reproduce (by stalling out / reducing-the-sampling-frequency for the main-thread animation of width).

With this testcase, I get this much older regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=204cda7581188cfc8c8ef11dce4680dadf2b43bb&tochange=f2915d3ee5f8705676e4bb643eab54b62246f25f

...in which the regression is likely:

Hiroyuki Ikezoe — Bug 1504065 - Run background-color animations on the compositor. r=birtles

I think this bug (on the Asus site as well as in the testcases) is just about cases where the compositor animation (for background-color) and main-thread animation (for width) are slightly out-of-sync, and we end up resetting the animation for the compositor to the starting color before we've gotten a chance to reset the main-thread animation. So we incorrectly draw the "animation-start" background-color onto an element with the "animation-end" size, for a single frame at least.

Comment 12

[Daniel Holbert [:dholbert]]

hiro, do you know if there's a bug tracking this issue (about animations on compositor vs. non-compositor getting reset in out-of-sync ways, such that we e.g. draw a background-color into a shape of the wrong size)?

I wonder if this is perhaps just an inevitable side effect of having a single element that has animations running on+off the compositor simultaneously.

I imagine the recommended way to avoid this would be to (in this case) run both animations on the compositor, i.e. to use transform:scale(...) instead of width/height for growing the "waves" in the Asus animation (using a small-but-nonzero starting width of course, so that we have something to scale). Though I don't know if we'd be able to get them to make that change in this case, and it might be worth mitigating this on our end if we have some way to do so...

Comment 13

[Brian Birtles (:birtles)]

hiro, do you know if there's a bug tracking this issue (about animations on compositor vs. non-compositor getting reset in out-of-sync ways, such that we e.g. draw a background-color into a shape of the wrong size)?

I wonder if this is perhaps just an inevitable side effect of having a single element that has animations running on+off the compositor simultaneously.

Note that we have a heuristic that prevents running transform animations on the compositor when we are animating other geometry properties on the main thread (like margin properties, width, height, etc.) because that produced similar issues on trello.com.

However, it turns out this optimization causes more problems than it's worth. See bug 1540906 where we are looking at turning this optimization off in release channels.

Comment 14

[Hiroyuki Ikezoe (:hiro)]

Thank you, Daniel! When I commented comment 4, I actually tried to disable dom.animations.mainthread-synchronization-with-geometric-animations which is the pref controlling the case what Brian commented in comment 13, but at that moment I did totally forget about the fact that the machinery is only used for transform animations.

Coincidentally, this year we introduced a new machinery to make scroll linked effect be sync (bug 1571758), I guess we can have a similar mechanism for animations. That said, it wouldn't be easy to implement.