Constant invalidation of svg content after animation on, due to FakeSmile continuously setting opacity & transform attributes



6 years ago
3 years ago


(Reporter: stebs, Unassigned)





(3 attachments)



6 years ago
Created attachment 693413 [details]
Output of about:support

1. enable nglayout.debug.paint_flashing
(2. perhaps disable harware accel.-my netbook is not able of hardw. accl.)
3. go to
4. move over the icons on top labeled "Home" "Blog" "Code" etc.

You see constant invalidation flickering even after animation of the icons stops, also high CPU utilisation.
This is a very old Bug, seen at least since Firefox/3.0.11 (on Windows XP) - see also

Just found out about nglayout.ddebug.paint_flashing and thought to report this again, despite the possibility this might be an Evangelism Bug.
Simpler STR:
 0. Enable paint flashing
 1. Visit
 2. Hover & un-hover an icon.

(The main site just has menu.svg displayed via an <object> tag)
Ever confirmed: true
Hardware: x86 → All
Summary: Constant invalidation of svg images after animation on (high cpu usage) → Constant invalidation of svg content after animation on (high cpu usage)
Version: unspecified → Trunk
Created attachment 693526 [details]
original SVG

Here's an attachment of menu.svg, as a testcase & in case codedread changes in such a way that we can't reproduce it there anymore.
The testcase pulls in "smil.user.js":
which is FakeSmile.

If I remove that script tag, then we get EXPECTED RESULTS -- animations still work (using native SMIL support), and the invalidations stop soon after you mouse off of an icon.

So, this seems to be a FakeSmile bug (e.g. repeatedly un-setting & setting the animated attribute, or something like that) -- not a gecko bug.
Created attachment 693533 [details]
SVG with FakeSmile script removed

Here's the SVG with the FakeSmile script removed, for comparison.
I suspected this might be a case where FakeSmile was repeatedly setting the same value over and over (and invalidating for no reason), but that's not the case.

If I put a breakpoint in SVGAnimatedTransformList::SetBaseValueString and print out the value, I see that we get alternating calls to set these values:

And if I place a breakpoint in nsICSSDeclaration::SetProperty, I see that we're getting alternating calls to set these values:

Given the above, our repeated invalidating is appropriate, & this is a site / JS-library bug.  Resolving INVALID as there's no Gecko bug here AFAICT.
Last Resolved: 6 years ago
Resolution: --- → INVALID
Or, probably better to morph into a Tech Evang bug -- sorry.
Assignee: nobody → english-us
Component: Layout → English US
Product: Core → Tech Evangelism
Resolution: INVALID → ---
Summary: Constant invalidation of svg content after animation on (high cpu usage) → Constant invalidation of svg content after animation on, due to FakeSmile continuously setting opacity & transform attributes
Version: Trunk → unspecified

Comment 7

4 years ago
Just revisited this old Bug of mine, with FF 30 and latest Nightly (34.0a1 (2014-07-26), both on Linux, I see no more difference of highlighting painted area between SVG with and without FakeSmile script.
Also high CPU utilisation is gone, there could be some minor residual CPU raise after triggering the svg animations (2% -> 6% in my case) though? 
So maybe this Bug is resolved?
Not sure about that, so leaving at Reopened for the moment...
Yeah, I don't see the continuous invalidation anymore. I *do* still see the never-ending alternating nsSVGAnimatedTransformList::SetBaseValueString() calls, as noted in comment 5. (BTW, I had to use the shield icon in the URL bar to let it load the external FakeSmile JS script off of, from attachment 693526 [details])

So, I suppose we can consider this fixed since the "constant invalidation" part is fixed. (I'm not 100% sure why the continuous changes aren't triggering invalidations/ paint; it might be because the transform is changing fast enough that we're coalescing the modifications and noticing that nothing changed, or it might be because the animation-target is hidden).

So, FakeSmile still has some problems, but it's not triggering continuous invalidation anymore. Whether that's a change on our end or theirs, this is WORKSFORME.
Last Resolved: 6 years ago4 years ago
Resolution: --- → WORKSFORME
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.