SMIL transform animation is frozen at intermediate state when switching to another tab & back, at Marek's "Cuba" demo

ASSIGNED
Assigned to

Status

()

Core
SVG
ASSIGNED
7 years ago
6 years ago

People

(Reporter: dholbert, Assigned: birtles)

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Created attachment 533546 [details]
testcase 1

STEPS TO REPRODUCE:
 1. Load attached testcase.

 2. Click document to trigger 'squish' animation

 3. Immediately (within a second), switch tabs or open new tab (Ctrl+PageUp/T)

 4. Wait 2 seconds to be sure 'squish' animation duration is complete, and then switch back to the tab with the testcase.

 4. If you don't get ACTUAL RESULTS yet, return to step 2.

ACTUAL RESULTS: When you return to the tab, some dominos are at intermediate states of the 'squish' animation.

EXPECTED RESULTS: Dominos should all be returned to their normal size.

Mozilla/5.0 (X11; Linux i686; rv:6.0a1) Gecko/20110518 Firefox/6.0a1
Hmm.  Do they then snap into position?  Or stay there?

If you disable the exponential backoff in background refresh drivers, does the problem go away?
Note: this testcase resists attempts at reducing. :) While it's not minimal, the current testcase is much simpler than the original demo, after some work by Marek & myself.
(In reply to comment #1)
> Hmm.  Do they then snap into position?  Or stay there?

They stay there.

> If you disable the exponential backoff in background refresh drivers, does the
> problem go away?

I'll give that a try, but maybe this answers that question:

Using a much less reduced testcase, I got the following regression range earlier today:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=75cc425bbaf0&tochange=e1d55bbd1d1d
.. in which bug 586201 ("Throttle refresh drivers in background tabs") looks like the most likely candidate.
Created attachment 533548 [details]
screenshot of bug
Hmm.  That was the fixed-duration throttling, before we switched to exponential backoff.

In that case, you should see the problem in Firefox 4.  If so, what values of "layout.throttled_frame_rate" show the problem?  I assume 60 does not but 1 does?

Would SMIL have problems with the refresh timer firing "too late" for some reason?
To be clear, that's a pref.  And it's live, so should be easy to test.
fwiw, I would assume we're hitting the SMIL sleep detection here, right?  Does that matter?
(In reply to comment #5)
> In that case, you should see the problem in Firefox 4.  If so, what values
> of "layout.throttled_frame_rate" show the problem?  I assume 60 does not but
> 1 does?

Correct. (in Firefox 4 -- not in nightlies, because as bz tells me on IRC, the pref means something completely different in nighlties.)

> Would SMIL have problems with the refresh timer firing "too late" for some
> reason?

By |firing "too late"|, do you mean "longer-than-normal time between samples", or "refresh driver lied about how much time had elapsed"?

It seems feasible that these could cause problems, but I'm not sure how, at the moment.

(In reply to comment #7)
> fwiw, I would assume we're hitting the SMIL sleep detection here, right?

I don't think we are, actually.  I don't see any instances of this warning being spammed, at least:
>  // Unexpectedly long delay between samples:
>  } else if (elapsedTime > SAMPLE_DEV_THRESHOLD * mAvgTimeBetweenSamples) {
>    NS_WARNING("Detected really long delay between samples, continuing from "
>               "previous sample");
>    mParentOffset += elapsedTime - mAvgTimeBetweenSamples;

...and I tried raising SAMPLE_DEV_THRESHOLD by 100x, too, and it didn't affect anything.

Note also that this sleep detection code was added in Nov 2010 (with Bug 606932), 3 months after the regression pushlog from comment 3.
Alternate STEPS TO REPRODUCE:
 1. Set about:config pref layout.frame_rate = 1 (or 2 or 3, if you like)
 2. Load testcase.
 3. Click document.  Watch to see if dominos return to their original state.

ACTUAL RESULTS: Most of the time, the dominos don't make it all the way back to their original state.
> By |firing "too late"|, do you mean "longer-than-normal time between samples", > or "refresh driver lied about how much time had elapsed"?

The former.

> Note also that this sleep detection code was added in Nov 2010 

OK, then.  It's not the problem.

Certainly given comment 9 it's not the problem.  Comment 9 just sounds like SMIL can't deal with very rare refresh driver notifications for some reason...
Yeah, agreed -- I think Comment 9 is the real bug here, and the regression range in Comment 3 just introduced a new way to hit it.
Confirmed against Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110519 Firefox/6.0a1 ID:20110519030627
OS: Linux → All
So from doing a targeted old build with a low-framerate code tweak...
> content/smil/nsSMILAnimationController.cpp
> -const PRUint32 nsSMILAnimationController::kTimerInterval = 22;
> +const PRUint32 nsSMILAnimationController::kTimerInterval = 1000;
...I hit this bug after bug 533291's csets landed (revision 9cdfc9ee6754) but not before (revision 5dd3f323fa37).
Blocks: 533291
Keywords: regression, testcase
Hardware: x86 → All
Summary: SMIL transform animation is frozen at intermediate state when switching to another tab & back, at Marek's upcoming "Cuba" demo → SMIL transform animation is frozen at intermediate state when switching to another tab & back, at Marek's "Cuba" demo
(Assignee)

Comment 14

6 years ago
(In reply to Boris Zbarsky (:bz) from comment #10)
> Certainly given comment 9 it's not the problem.  Comment 9 just sounds like
> SMIL can't deal with very rare refresh driver notifications for some
> reason...

SMIL (and our implementation of it) should be totally independent of sample rate. If it's not, it's a bug.

My suspicion is we're ignoring the sample or filtering it out for some reason.
Assignee: nobody → birtles
Status: NEW → ASSIGNED
> My suspicion is we're ignoring the sample or filtering it out for some reason.

Per comment 13, bug 533291 appears to have regressed this -- so it looks like we're incorrectly thinking that our animations haven't changed when actually they have.
To clarify: I think the issue is something to do with the switch from active to inactive -- we (incorrectly) think that nothing's changed on that first inactive sample, & we don't bother recompositing.

The low frame rate only matters insomuch as it makes that mistake more obvious, because it means that our final composited frame is from somewhere in the middle of the simple duration rather than somewhere very close to the end.
Duplicate of this bug: 733744
You need to log in before you can comment on or make changes to this bug.