Open Bug 302909 Opened 19 years ago Updated 2 years ago

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


(Core :: SVG, defect, P4)

Windows XP




(Reporter: w.langdon, Unassigned)




(Keywords: perf, Whiteboard: [invalidation] [in-the-wild] [external-report][dup of bug 1009693?])


(4 files, 1 obsolete file)

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

Component: General → SVG
Product: Firefox → Core
Version: unspecified → 1.8 Branch
That URL gives a "connection refused" error...  Bill, is there a URL that shows the problem that I could access?
(In reply to comment #1)
> That URL gives a "connection refused" error...  
My site, has been down. 
It is ok now.

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.
Ever confirmed: true
Whiteboard: [cairo-perf]
Assignee: nobody → general
QA Contact: general → ian
Blocks: 334719
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
Assignee: general → nobody
Keywords: perf
QA Contact: ian → general
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
err, nevermind, that was the wrong thing.  I'm getting 50%
Version: 1.8 Branch → Trunk
so in couple of years CPU will fix this bug
Attached file Reporter's testcase (obsolete) —
Attaching testcase just to make sure we still have it if the source site disappears.
Firefox 17 uses 0% of CPU. Firefox 19 (20121022) uses 7%.
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.
The testcase animates the 'top' and 'left' properties of the <div> wrapping the 
SVG snowflakes. That will cause reflow which is why we repaint.
Depends on: 745485, 876321
Whiteboard: [cairo-perf] → [jwatt:invalidation]
Whiteboard: [jwatt:invalidation] → [jwatt:invalidation] [in-the-wild]
Priority: -- → P4
Whiteboard: [jwatt:invalidation] [in-the-wild] → [jwatt:invalidation] [in-the-wild] [external-report]
Attached image SVG snowflake
Attachment #8500013 - Attachment mime type: text/plain → image/svg+xml
Attached image background gif
Attached file Reporter's testcase
Attachment #601334 - Attachment is obsolete: true
Attached file 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?
Flags: needinfo?(roc)
Depends on: 1009693
Yes it is.
Flags: needinfo?(roc)
Whiteboard: [jwatt:invalidation] [in-the-wild] [external-report] → [invalidation] [in-the-wild] [external-report][dup of bug 1009693?]
Summary: SVG performance heavy CPU load on javascript moving graphic → Unnecessary invalidation of SVG in <object> while animating 'top' and 'left' properties
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.