GNOME Bugzilla – Bug 334444
Opening an e-mail with 10 attachments lags horribly
Last modified: 2008-04-21 05:11:19 UTC
Distribution: Ubuntu 6.04 (dapper) Package: Evolution Priority: Normal Version: GNOME2.13.92 unspecified Gnome-Distributor: Ubuntu Synopsis: Opening an e-mail with 10 attachments lags horribly Bugzilla-Product: Evolution Bugzilla-Component: Mailer Bugzilla-Version: unspecified Description: Description of Problem: I recieved a bunch of e-mails with 10 vacation photos each. Opening one of the messages in Evolution lags out my system for about 5 seconds before it loads Steps to reproduce the problem: 1. Recieve an e-mail with many attachments 2. Watch it lag Expected Results: Shouldn't take that long to load a message since it isn't actually displaying the photos anyway. How often does this happen? Every time. Additional Info: Pentium M 1.6ghz 10x 740kb photos ------- Bug created by bug-buddy at 2006-03-13 14:48 -------
but it seems like evo produces thumbnails.
I can confirm this in a different way. I tried forwarding about 29 contacts as seperated vcf files but when evolution tried to display the message it was horribly slow. Then when changing the collapsed/uncollapsed state of the contacts it would also take a good amount of time (over 10 seconds on a PIV@2.2Ghz). From a user POV this is completely ugly since the UI is completely frozen in the meantime.
Gilles, could you try this on actual SVN version? There was committed a patch on 2007-05-15 from bug #433782 and it may help with vcf files (especially on large vCards). Stu, I composed an HTML mail with 10 photos, between 600KB and 1MB each, and only save it as Draft, and nothing wrong happened. All works fine, I could see no application lag. It was simple HTML mail, maybe that lag could have something with bug #435620 ? The lag is only when downloading images from an account, but the application isn't freeze, you could change to other mail (and it crashes when downloading images from server (not in cache yet), but it's about bug #338921 or bug #434262, I'm not sure which one). Maybe I'm doing something wrong or this was fixed as side-effect of other bug?
You're probably right that this was just a network connection problem. But, I probably should have mentioned in the original posting that this was with a POP3 account, not IMAP. Doesn't POP3 need to download the message to display it? Hence, if I was able to click the message in the interface, the photos should have all been fetched already as part of the message body, correct? Since I posted this I've switched to IMAP, which (I think) has a an excuse for lagging in this situation.
Yes, of course, you need to download messages before display, that's right. You could have in message links on external images too, and it was my mistake that I did a message with "inline" pictures (neither links on external images, nor attachments). When I put those pictures as attachments, then it has a lag, in status bar is "Formatting message" and it takes about 3 seconds for me. As Andre said, it looks like that's because of those thumbnails, and could be "proved" with my mistake, because with inline messages it didn't produce thumbnails and it is quick enough. BTW, it did in my sent box too, so it is not obviously about account type. I'm not sure what could be done with this then, maybe an option about generate/don't generate thumbnails would help?
if the slowness is indeed the thumbnailing (you'd have to do some profiling to be sure), then the 2 options you have are: 1. see if the thumbnailing code can be optimized 2. (optionally) don't thumbnail and use a generic "image" icon instead
(In reply to comment #3) > Gilles, could you try this on actual SVN version? There was committed a patch > on 2007-05-15 from bug #433782 and it may help with vcf files (especially on > large vCards). I just checked with svn trunk of evo and eds and also the vCard stuff is now ok (near instant display of big photos) in the addressbook, the formating of 30 vCards in mail view takes about 24 seconds on a PIII 500. I'll try to do some oprofile or sysprof to get a clue about what takes so much time if it fits this bug report (probably something to optimize in itip-formater).
(In reply to comment #6) > if the slowness is indeed the thumbnailing (you'd have to do some profiling to > be sure), then the 2 options you have are: > > 1. see if the thumbnailing code can be optimized > 2. (optionally) don't thumbnail and use a generic "image" icon instead > I tested this and it's on my machine as follows: Almost all time consumes calling of gdk_pixbuf_loader_write function, all other part of this code is for 30-40ms (calling gdk_pixbuf_loader_write was for 270ms for jpeg size 2192x1252 and 130ms/140ms for jpegs size 2288x1712, based on different compressions, I think).
Bumping version to a stable release.
*** Bug 514813 has been marked as a duplicate of this bug. ***
Created attachment 107063 [details] another sample Bug 514813 contains sample spam mail with attachments too. I attached other sample mail, it flashes when loading it. It doesn't contain any attachment, though. Notice also broken border near dvdisaster-0.70.4-3.fc9
Created attachment 109420 [details] [review] Proposed patch
I tested my patch with a mail that had 500+ attachments and it works fine with that. It was due to a horrible code I wrote few years back. This solves the problem. What happened was everytime a attachment was added the entire attachment bar was redrawn. So for 10 attachments it will be redras 1+2+3+4...10 times. I made it just do once after all the attachments were added. It make huge difference with that 500 attachment mail.
Committed to stable/trunk.