https://bugzilla.novell.com/show_bug.cgi?id=376710 Summary: mails with lots of attachments ... Product: openSUSE 11.0 Version: Factory Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Evolution AssignedTo: bnc-team-evolution@forge.provo.novell.com ReportedBy: mmeeks@novell.com QAContact: lakhil@novell.com CC: federico@novell.com Found By: --- I have a mail with 140+ attachments to it, and selecting this mail in Evolution causes some hideous performance problems. GtkHtml consumes an immense time updating it's display. It seems a large amount of that time (from a non-scientific set of ctrl-c backtraces) in gdb is consumed simply rendering the same SVG attachment icon again and again. This trace is typical: (gdb) bt #0 0xb6d49f69 in _cairo_slope_compare (a=0xbf852314, b=0x145a3a10) at cairo-slope.c:67 #1 0xb6d49fc8 in _cairo_slope_clockwise (a=0xbf852314, b=0x145a3a10) at cairo-slope.c:98 #2 0xb6d4638a in _cairo_pen_find_active_cw_vertex_index (pen=0xbf8525a8, slope=0xbf852314, active=0xbf85232c) at cairo-pen.c:320 #3 0xb6d46445 in _cairo_pen_stroke_spline_half (pen=0xbf8525a8, spline=<value optimized out>, dir=CAIRO_DIRECTION_FORWARD, polygon=0xbf85236c) at cairo-pen.c:407 #4 0xb6d4666b in _cairo_pen_stroke_spline (pen=0xbf8525a8, spline=0xbf8524ac, tolerance=0.10000000000000001, traps=0xbf852794) at cairo-pen.c:461 #5 0xb6d459be in _cairo_stroker_curve_to (closure=0xbf852650, b=0x147cec14, c=0x147cec1c, d=0x147cec24) at cairo-path-stroke.c:905 #6 0xb6d439db in _cairo_path_fixed_interpret (path=0x147ceb70, dir=CAIRO_DIRECTION_FORWARD, move_to=0xb6d44cc0 <_cairo_stroker_move_to>, line_to=0xb6d459d0 <_cairo_stroker_line_to>, curve_to=0xb6d456f0 <_cairo_stroker_curve_to>, close_path=0xb6d46010 <_cairo_stroker_close_path>, closure=0xbf852650) at cairo-path-fixed.c:483 #7 0xb6d44f4f in _cairo_path_fixed_stroke_to_traps (path=0x147ceb70, stroke_style=0x143e0e90, ctm=0xbf852b18, ctm_inverse=0xbf852ae8, tolerance=0.10000000000000001, traps=0xbf852794) at cairo-path-stroke.c:1062 #8 0xb6d4ee65 in _cairo_surface_fallback_stroke (surface=0x143eea38, op=CAIRO_OPERATOR_OVER, source=0xbf852a54, path=0x147ceb70, stroke_style=0x143e0e90, ctm=0xbf852b18, ctm_inverse=0xbf852ae8, tolerance=0.10000000000000001, antialias=CAIRO_ANTIALIAS_DEFAULT) at cairo-surface-fallback.c:837 #9 0xb6d4c1a9 in _cairo_surface_stroke (surface=0x143eea38, op=CAIRO_OPERATOR_OVER, source=0xbf852b98, path=0x147ceb70, stroke_style=0x143e0e90, ctm=0x143e0f38, ctm_inverse=0x143e0f68, tolerance=0.10000000000000001, antialias=CAIRO_ANTIALIAS_DEFAULT) at cairo-surface.c:1421 #10 0xb6d3e490 in _cairo_gstate_stroke (gstate=0x143e0e80, path=0x147ceb70) at cairo-gstate.c:975 #11 0xb6d3680d in *INT_cairo_stroke_preserve (cr=0x147cea00) at cairo.c:2053 #12 0xb6d36832 in cairo_stroke (cr=0x147cea00) at cairo.c:2027 #13 0xb008b400 in rsvg_cairo_render_path (ctx=0x14595100, bpath_def=0x13b228b8) at rsvg-cairo-draw.c:634 #14 0xb0085e9e in rsvg_render_path (ctx=0x14595100, d=0x14757f58 "M -141.46875,-55.5 C -142.05192,-55.5 -142.5,-55.051916 -142.5,-54.46875 L -142.5,-17.53125 C -142.5,-16.948085 -142.05191,-16.5 -141.46875,-16.5 L -110.53125,-16.5 C -109.94808,-16.5 -109.5,-16.94808"...) at rsvg-base.c:1678 #15 0xb007b0ab in rsvg_node_path_draw (self=0x1422a380, ctx=0x14595100, dominate=0) at rsvg-shapes.c:60 #16 0xb007dbf1 in rsvg_node_draw (self=0xffffffff, ctx=0x14595100, dominate=0) at rsvg-structure.c:53 #17 0xb007de4a in _rsvg_node_draw_children (self=0x13dcee40, ctx=0x14595100, dominate=0) at rsvg-structure.c:69 #18 0xb007dbf1 in rsvg_node_draw (self=0xffffffff, ctx=0x14595100, dominate=0) at rsvg-structure.c:53 #19 0xb007de4a in _rsvg_node_draw_children (self=0x140e3b98, ctx=0x14595100, dominate=0) at rsvg-structure.c:69 #20 0xb007dbf1 in rsvg_node_draw (self=0xffffffff, ctx=0x14595100, dominate=0) at rsvg-structure.c:53 #21 0xb007de4a in _rsvg_node_draw_children (self=0x13a5c5f8, ctx=0x14595100, dominate=0) at rsvg-structure.c:69 #22 0xb007dbf1 in rsvg_node_draw (self=0xffffffff, ctx=0x14595100, dominate=0) at rsvg-structure.c:53 #23 0xb007de4a in _rsvg_node_draw_children (self=0x1405a728, ctx=0x14595100, dominate=0) at rsvg-structure.c:69 #24 0xb007dbf1 in rsvg_node_draw (self=0xffffffff, ctx=0x14595100, dominate=0) at rsvg-structure.c:53 #25 0xb007ea1a in rsvg_node_svg_draw (self=0x14067a00, ctx=0x14595100, dominate=0) at rsvg-structure.c:309 #26 0xb007dbf1 in rsvg_node_draw (self=0xffffffff, ctx=0x14595100, dominate=0) at rsvg-structure.c:53 #27 0xb008c024 in rsvg_handle_render_cairo_sub (handle=0x1477aad8, cr=0x147cea00, id=0x0) at rsvg-cairo-render.c:228 #28 0xb008c576 in rsvg_handle_get_pixbuf_sub (handle=0x1477aad8, id=0x0) at rsvg.c:100 #29 0xb008c615 in rsvg_handle_get_pixbuf (handle=0x1477aad8) at rsvg.c:133 #30 0xb00f6b6a in gdk_pixbuf__svg_image_stop_load (data=0x13d7af48, error=0xbf853288) at io-svg.c:154 #31 0xb6e016b4 in IA__gdk_pixbuf_loader_close (loader=0x14723530, error=0x1364df44) at gdk-pixbuf-loader.c:724 #32 0xb7118fb6 in icon_info_ensure_scale_and_pixbuf (icon_info=0x1364df20, scale_only=<value optimized out>) at gtkicontheme.c:2781 #33 0xb71195b1 in IA__gtk_icon_info_load_icon (icon_info=0x1364df20, error=0x0) at gtkicontheme.c:2939 #34 0xb711b62b in IA__gtk_icon_theme_load_icon (icon_theme=0x8091850, icon_name=0x142f9f88 "gnome-fs-regular", size=48, flags=GTK_ICON_LOOKUP_USE_BUILTIN, error=0x0) at gtkicontheme.c:1537 #35 0xb7ec155e in e_icon_for_mime_type (mime_type=0x13ed0e80 "message/rfc822", size_hint=48) at e-gui-utils.c:57 #36 0xb7fe08fb in update (bar=0x104281a0) at e-attachment-bar.c:371 #37 0xb7fe0d48 in add_common (bar=0x104281a0, attachment=0x146c7890) at e-attachment-bar.c:135 #38 0xb31f9d9d in efhd_attachment_button (efh=0x8295d88, eb=0x14763600, pobject=0x147c6148) at em-format-html-display.c:1882 Inserting a breakpoint shows: Breakpoint 1, e_icon_for_mime_type (mime_type=0x147522e8 "message/rfc822", size_hint=48) at e-gui-utils.c:56 56 if (icon_name != NULL) { (gdb) c 100 Will ignore next 99 crossings of breakpoint 1. Continuing. Breakpoint 1, e_icon_for_mime_type (mime_type=0x1444a990 "message/rfc822", size_hint=48) at e-gui-utils.c:56 56 if (icon_name != NULL) { (gdb) c 100 Will ignore next 99 crossings of breakpoint 1. Continuing. Breakpoint 1, e_icon_for_mime_type (mime_type=0x13895100 "message/rfc822", size_hint=48) at e-gui-utils.c:56 56 if (icon_name != NULL) { (gdb) c 100 Will ignore next 99 crossings of breakpoint 1. Continuing. Breakpoint 1, e_icon_for_mime_type (mime_type=0x137fee48 "application/pgp-signature", size_hint=48) at e-gui-utils.c:56 56 if (icon_name != NULL) { (gdb) c 100 Will ignore next 99 crossings of breakpoint 1. Continuing. Breakpoint 1, e_icon_for_mime_type (mime_type=0x13e30160 "message/rfc822", size_hint=48) at e-gui-utils.c:56 56 if (icon_name != NULL) { (gdb) c 200 Will ignore next 199 crossings of breakpoint 1. Continuing. Breakpoint 1, e_icon_for_mime_type (mime_type=0x14442cd0 "message/rfc822", size_hint=48) at e-gui-utils.c:56 56 if (icon_name != NULL) { (gdb) c 250 Will ignore next 249 crossings of breakpoint 1. Continuing. Breakpoint 1, e_icon_for_mime_type (mime_type=0x144950b8 "message/rfc822", size_hint=48) at e-gui-utils.c:56 56 if (icon_name != NULL) { (gdb) c 500 Will ignore next 499 crossings of breakpoint 1. Continuing. [New Thread 0xb0b8cb90 (LWP 22156)] [New Thread 0xb142cb90 (LWP 22157)] [Thread 0xb142cb90 (LWP 22157) exited] Breakpoint 1, e_icon_for_mime_type (mime_type=0x13b5be40 "message/rfc822", size_hint=48) at e-gui-utils.c:56 56 if (icon_name != NULL) { ie. we call this one methods -thousands- of times [ for no apparent reason ]. Now - of course, the underlying problem is that there is clearly some N^N (at least) operation going on here from: #0 e_icon_for_mime_type (mime_type=0x13b5be40 "message/rfc822", size_hint=48) at e-gui-utils.c:56 #1 0xb7fe08fb in update (bar=0x104281a0) at e-attachment-bar.c:371 #2 0xb7fe0d48 in add_common (bar=0x104281a0, attachment=0x146c7a40) at e-attachment-bar.c:135 #3 0xb31f9d9d in efhd_attachment_button (efh=0x8295d88, eb=0x14775508, pobject=0x147c6ac8) at em-format-html-display.c:1882 #4 0xb31fb329 in efh_object_requested (html=0x8263150, eb=0x14775508, efh=0x8295d88) at em-format-html.c:624 #5 0xb7a170a6 in html_g_cclosure_marshal_BOOLEAN__OBJECT (closure=0x8d4e060, return_value=0xbf8538f8, n_param_values=2, param_values=0xbf853738, invocation_hint=0xbf853674, marshal_data=0xb31fb2d0) at htmlmarshalc:83 #6 0xb69dcc3b in IA__g_closure_invoke (closure=0x8d4e060, return_value=0xbf8538f8, n_param_values=2, param_values=0xbf853738, invocation_hint=0xbf853674) at gclosure.c:490 #7 0xb69f141d in signal_emit_unlocked_R (node=0x82e77c0, detail=0, instance=0x8263150, emission_return=0xbf8538f8, instance_and_params=0xbf853738) at gsignal.c:2440 #8 0xb69f27d8 in IA__g_signal_emit_valist (instance=0x8263150, signal_id=327, detail=0, var_args=0xbf853950 "`9\205�h�\b\2109\205���\235�") at gsignal.c:2209 #9 0xb69f2db6 in IA__g_signal_emit (instance=0x8263150, signal_id=327, detail=0) at gsignal.c:2243 #10 0xb79d28ec in html_engine_object_requested_cb (engine=0x83025a0, eb=0x14775508, data=0x8263150) at gtkhtml.c:541 #11 0xb7a170a6 in html_g_cclosure_marshal_BOOLEAN__OBJECT (closure=0x8d4fb68, return_value=0xbf853d68, n_param_values=2, param_values=0xbf853ba8, invocation_hint=0xbf853ae4, marshal_data=0xb79d2890) at htmlmarshalc:83 #12 0xb69dcc3b in IA__g_closure_invoke (closure=0x8d4fb68, return_value=0xbf853d68, n_param_values=2, param_values=0xbf853ba8, invocation_hint=0xbf853ae4) at gclosure.c:490 #13 0xb69f141d in signal_emit_unlocked_R (node=0x82e83b0, detail=0, instance=0x83025a0, emission_return=0xbf853d68, instance_and_params=0xbf853ba8) at gsignal.c:2440 #14 0xb69f27d8 in IA__g_signal_emit_valist (instance=0x83025a0, signal_id=349, detail=0, var_args=0xbf853dc0 "\b>\205�����@\021\217�") at gsignal.c:2209 #15 0xb69f2db6 in IA__g_signal_emit (instance=0x83025a0, signal_id=349, detail=0) at gsignal.c:2243 #16 0xb7a06771 in element_parse_object (e=0x83025a0, clue=0x14a861c0, attr=0x14a7a74b "object classid=\"attachment.0x8e3c958.17408.mixed.186.rfc822\">") at htmlengine.c:1531 #17 0xb7a046cd in parse_one_token (e=0x83025a0, clue=0x14a861c0, str=0x14a7a74b "object classid=\"attachment.0x8e3c958.17408.mixed.186.rfc822\">") at htmlengine.c:3749 #18 0xb7a0cd29 in html_engine_timer_event (e=0x83025a0) at htmlengine.c:1347 #19 0xb6958b96 in g_timeout_dispatch (source=0x14866b00, callback=0x13b5be40, user_data=0x83025a0) at gmain.c:3437 #20 0xb6958468 in IA__g_main_context_dispatch (context=0x8094378) at gmain.c:2003 #21 0xb695bb23 in g_main_context_iterate (context=0x8094378, block=1, dispatch=1, self=0x8068290) at gmain.c:2636 #22 0xb695c042 in IA__g_main_loop_run (loop=0x8130130) at gmain.c:2844 #23 0xb748d0a3 in bonobo_main () at bonobo-main.c:311 #24 0x0805e1b5 in main (argc=1, argv=0xb6a7ed30) at main.c:782 Which will cause -loads- of problems too; however - clearly we could ~easily avoid re-rendering the same icon again and again at considerable expense. The question is: why does this happen at all - does gtk+ or gnome_icon not have some nice cache to help ? [ Federico ? ]. If not, a single-entry cache in e-gui-utils.c should help a lot I think. Could it be that the size-hint we pass means that we don't have a bitmap version of this svg cached we can trivially re-use ? Do we even build bitmap versions of svg icons to cache them in the shared icon cache Federico ? [ we clearly should ]. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.