I'm seeing the CPU maxed out constantly by SMIL when fill="freeze", even after the active duration has ended. I'll attach a testcase. There are probably two fixes that are needed here. 1) Don't resample a frozen animation after it's been frozen 2) Don't tell elements that they have changed when the animated value has not changed since the last sample

I threw the filter in there just to make the invalidation more expensive so that it's noticeable that we just keep on invalidating the rect continuously.

(In reply to comment #0) > 1) Don't resample a frozen animation after it's been frozen It's supposed to do that already but I think Daniel's commented that bit out until we add HasChangedTarget. See: http://mxr.mozilla.org/mozilla-central/source/content/smil/nsSMILCompositor.cpp#153 Also, if there are any timing model related issues here then I'd rather just mark it dependent on bug 474743 since that changes the timing model a lot. > 2) Don't tell elements that they have changed when the animated value > has not changed since the last sample Yeah, that's good too. I think that was always the plan but it doesn't look like we're doing it yet.

(In reply to comment #3) > (In reply to comment #0) > > 1) Don't resample a frozen animation after it's been frozen > > It's supposed to do that already but I think Daniel's commented that bit out > until we add HasChangedTarget. Bug 533291 will address this part.

Just landed Bug 533291, which fixes this bug in my debug build. (CPU usage goes back to normal after animation completes.) Resolving.

Sweet. :-)