302909 - Unnecessary invalidation of SVG in <object> while animating 'top' and 'left' properties

Status: NEW

(Core :: SVG, defect, P4)

Description

[bill]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050717 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050717 Firefox/1.0+

Page designed to measure CPU+memory usage of Deerpark with on moving SVG graphics.
Load approx 66 times that of moving similar graphic as GIF. Memory usage similar.

ps: Why does bugzilla search with more keywords produce _more_ hits?

Reproducible: Always

Steps to Reproduce:
1. load http://www.cs.ucl.ac.uk/staff/W.Langdon/svg_performance.html
2. Should display 5 koch snow flakes (white with blue stroke) on a tartan      
background. The SVG graphics will move slowly at random. The background will
flicker. (I think the background fliker with SVG has been reported elsewhere).
3. Measure CPU load. on 3Ghz CPU should be about 50%.
(On moving away from page and reloading, SVGs may not be redisplayed, but
background will fliker--failure to redisplay SVGs reported elsewhere).

Actual Results:  
CPU loading hovers near 50%

Expected Results:  
If similarly sized GIF is used instead (uncomment a couple of lines near top
of example javascript) 330 images can be loaded and animated for at approx the
same CPU loading.

Thank you

Bill

Comment 1

[Boris Zbarsky [:bzbarsky]]

That URL gives a "connection refused" error...  Bill, is there a URL that shows the problem that I could access?

Comment 2

[bill]

(In reply to comment #1)
> That URL gives a "connection refused" error...  
My site, http://www.cs.ucl.ac.uk/staff/W.Langdon/ has been down. 
It is ok now.
Bill 

Comment 3

[Boris Zbarsky [:bzbarsky]]

Ok, I did a profile of that testcase (on Linux, so applicability to Windows should be taken with a grain of salt, I guess):

Total hit count: 147512
Count %Total  Function Name
70233   47.6     select
5956   4.0     __udivmoddi4
5758   3.9     bsearch
5482   3.7     memcpy
5190   3.5     __mempcpy
3617   2.5     _cairo_traps_tessellate_polygon
3305   2.2     __libc_calloc
3085   2.1     _compute_x
3053   2.1     __divdi3

All of the select() stuff is waiting on X to respond.  Looking from the top down instead, we have:

  129286 nsSVGCairoPathGeometry::Render(nsISVGRendererCanvas*)

(so that's almost all the time), with this breaking down as:

       118515 cairo_stroke
         7558 cairo_fill_preserve
         3087 nsSVGCairoPathGeometry::GeneratePath(_cairo*, nsISVGCairoCanvas*)

Digging down into cairo_stroke, it breaks down more or less as:

        59733 _cairo_gstate_clip_and_composite_trapezoids
        58519 _cairo_path_fixed_stroke_to_traps

The former ends up completely in XRenderCompositeTrapezoids, which then ends up in _XSend and thence select().

The latter ends up in cairo_stroker_line_to which breaks down as:

        30192 _cairo_stroker_add_sub_edge
        26859 _cairo_stroker_join

Both of those end up mostly in _cairo_traps_tessellate_polygon, where we spend time as follows:

 87804 3617    44803 _cairo_traps_tessellate_polygon
              18307 qsort
              13782 _line_segs_intersect_ceil
               4685 _compute_x
               2766 _cairo_traps_add_trap
               1069 memmove
                121 bsearch

So whatever cairo is doing here is should really try to do it faster... or something.  The other possibility, of course, is that we make a huge number of calls into cairo, but given the small amount of our code where time is spent, I kinda doubt that's the only issue.

Comment 4

[Wayne Mery (:wsmwk)]

I'm seeing 95%+ cpu on a w2k machine.  Looks even more interesting via remote desktop. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070427 Minefield/3.0a4pre

~50% on xp with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070527 Minefield/3.0a5pre

Comment 5

[David Zbarsky (:dzbarsky)]

I'm getting around 4-6% cpu on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre)
Gecko/2007071405 Minefield/3.0a7pre

Comment 6

[David Zbarsky (:dzbarsky)]

err, nevermind, that was the wrong thing.  I'm getting 50%

Comment 7

[Jaroslav Zaruba]

28-35pct
so in couple of years CPU will fix this bug

Comment 8

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Looks fixed...

Comment 9

[Jonathan Watt [:jwatt]]

Attachment: Reporter's testcase

Attaching testcase just to make sure we still have it if the source site disappears.

Comment 10

[Guilherme Lima]

Firefox 17 uses 0% of CPU. Firefox 19 (20121022) uses 7%.

Comment 11

[Wayne Mery (:wsmwk)]

Testcase seems to not work for recent Firefox - no images seen with FF trunk or FF16.0a1 from July 16.

in IE, "images" of attachment 601334 [details] do appear.

Comment 12

[Jonathan Watt [:jwatt]]

The testcase animates the 'top' and 'left' properties of the <div> wrapping the 
SVG snowflakes. That will cause reflow which is why we repaint.

Comment 13

[Jonathan Watt [:jwatt]]

Attachment: SVG snowflake

Comment 14

[Jonathan Watt [:jwatt]]

Attachment: background gif

Comment 15

[Jonathan Watt [:jwatt]]

Attachment: Reporter's testcase

Comment 16

[Jonathan Watt [:jwatt]]

Attachment: reduced testcase

It seems that although bug 745485 and bug 876321 are fixed, if the <img>'s 'left' property is set to a fractional value then we will invalidate the <img>'s SVG as the <img> moves.

roc, is this expected?

Comment 17

[Markus Stange [:mstange]]

That's bug 1009693.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes it is.