822677 - Constant invalidation of svg content after animation on codedread.com, due to FakeSmile continuously setting opacity & transform attributes

Status: RESOLVED WORKSFORME

(Tech Evangelism Graveyard :: English US, defect)

Description

[Stebs]

Attachment: 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 http://www.codedread.com/
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 https://bugzilla.mozilla.org/show_bug.cgi?id=451594#c3

Just found out about nglayout.ddebug.paint_flashing and thought to report this again, despite the possibility this might be an Evangelism Bug.

Comment 1

[Daniel Holbert [:dholbert]]

Simpler STR:
 0. Enable paint flashing
 1. Visit http://www.codedread.com/menu.svg
 2. Hover & un-hover an icon.

(The main codedread.com site just has menu.svg displayed via an <object> tag)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: 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.

Comment 3

[Daniel Holbert [:dholbert]]

The testcase pulls in "smil.user.js":
  http://www.codedread.com/lib/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.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: SVG with FakeSmile script removed

Here's the SVG with the FakeSmile script removed, for comparison.

Comment 5

[Daniel Holbert [:dholbert]]

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:
 scale(1,1)
and
 scale(0.8,0.8)


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

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.

Comment 6

[Daniel Holbert [:dholbert]]

Or, probably better to morph into a Tech Evang bug -- sorry.

Comment 7

[Stebs]

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...

Comment 8

[Daniel Holbert [:dholbert]]

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 codedread.com, 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.