1693016 - SVG mask keyframes animation is throttled / choppy when masking element is outside of the viewport

Status: NEW

(Core :: DOM: Animation, defect)

Description

[Michal Čaplygin [:myf]]

Attachment: SVG mask animation crossing viewport boundary Firefox stutter test.html

Attached testcase contains four SVG elements filled with rectangle in group that is masked by other rectangle (each SVG contains own mask). Masking rectangles are animated via CSS keyframes translating them back and forth.

Masks animations runs smoothly to the point when (presumably) effective top left corners of masking elements exceed actual viewport, then animation starts to be choppy - best observed on the last SVG in test page: it is smooth when page is scrolled to the top, but becomes choppy when page is scrolled so the last SVG is partially outside viewport.

Comment 1

[Emilio Cobos Álvarez [:emilio]]

We're incorrectly thinking that the <rect> is scrolled out of view here.

Comment 2

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1693016 - Potential fix: Don't throttle animations of observed elements.

Not a fan of this since this would cause us to use more CPU if the thing
that observes is actually out of view... We already disable async
animations for these elements. Maybe we want to instead check if the
elements referencing us are out of view.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

So there are sort of two issues here... First, the masked <rect> is 0x0 in the frame tree. It's inside a <mask>, but I'd still have expected it to have the right size. If it did, this particular case would be working (and it might be good enough of a solution).

The other issue is that we're actually accounting for the mask itself, not for the element that is using it... That seems like another issue, at least. Though in this case the origins are the same so it wouldn't matter.

Not sure what's the best solution here. I attached a patch that fixes the issue, but is extremely conservative and we probably don't want to take as-is.

Comment 4

[Robert Longson [:longsonr]]

masks and their contents will have frames that have NS_FRAME_IS_NONDISPLAY set. Perhaps we could use that? We don't size NONDISPLAY items in frame trees because they are only indirectly rendered.

If the mask is smaller than the element, you'd only display the mask bounds so the second paragraph sounds like we're doing the right thing.

Comment 5

[Emilio Cobos Álvarez [:emilio]]

Well, we're actually using the size of the <rect>, not the <mask>... But yeah, maybe just check that bit, go to the root of the NONDISPLAY subtree, and check for the contents that are observing it.

Comment 6

[Daniel Cicas [:dcicas], Release QA]

Hello!

I looked into the regression range for this issue and it seems broken from at least 2018-2019. I think this is not a regression. I'm removing the "regression" and "regressionwindow-wanted" keywords.

Comment 7

[Samuel Degueldre]

See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1421506#c3

Comment 10

[Emilio Cobos Álvarez [:emilio]]

The WIP patch in bug 1693016 would fix it, but as noted there is not ideal. Ideally, we want to check that at least some of the things that reference us are visible...