Open Bug 302909 Opened 17 years ago Updated 5 years ago
Unnecessary invalidation of SVG in <object> while animating 'top' and 'left' properties
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, http://www.cs.ucl.ac.uk/staff/W.Langdon/ has been down. It is ok now. Bill
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
No longer 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
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%
28-35pct so in couple of years CPU will fix this bug
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.
Whiteboard: [jwatt:invalidation] → [jwatt:invalidation] [in-the-wild]
Priority: -- → P4
Whiteboard: [jwatt:invalidation] [in-the-wild] → [jwatt:invalidation] [in-the-wild] [external-report]
Attachment #8500013 - Attachment mime type: text/plain → image/svg+xml
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?
That's bug 1009693.
Yes it is.
Whiteboard: [jwatt:invalidation] [in-the-wild] [external-report] → [invalidation] [in-the-wild] [external-report][dup of bug 1009693?]
You need to log in before you can comment on or make changes to this bug.