GNOME Bugzilla – Bug 524338
mail rendering flickers a lot when displaying a message
Last modified: 2008-05-19 03:12:20 UTC
when sifting from one message to another, one can see a lot of flickering going on in the message pane. It seems everything is redrawn each time. Can anything be done about that? Maybe this reflects some part of the ui logic that could benefit from some optimization?
no, it's the "don't display messages that are bigger than X kilobytes" feature to avoid a denial of service
I don't understand, could you elaborate what this is about (when you have a minute)? I don't see how preventing the display of huge sized messages makes it so that everytime you switch from a message to another, everything flickers as if the entire message pane/window was redrawn?
Created attachment 110612 [details] sysprof http://jeff.ecchi.ca/public/524338.ogv You have *got* to do something about this flickering! Other mail clients have no such strangeness that I could see (and I just tested balsa, claws, thunderbird). I am attaching a sysprof I ran while triggering this, I hope I did it correctly, and that it helps. Please confirm this bug if it does.
Created attachment 110613 [details] sample message This is the sample message that you could see in the video (link provided in comment #3)
fwiw, I get this same exact problem on a lot of my mails as well - seems to be related to the length of the message (usually text/plain?). The folders of mine that gets this behavior the most often are the cvs-commits-list folders. Awesome that you made a video of this.
Yes, it does depend on mail size obviously. Large mail will flash. Feels like it is being rendered more than once, in progressive chunks, or something. If so, a way better solution would be to delay rendering, until the message has been fetched entirely. Half a second of waiting is less annoying, than that flickering. Quick poll: Anyone seen this for local (POP3) mail? IMAP only?
I get this for messages in local folders (I switched to POP a year ago)
it's a side effect of the workaround to avoid large DoS attacks. also see the "don't display message parts larger than X bytes" setting in the prefs.
I just un-checked this preference, and the flicker still happens the same. Is this really the cause? On a side note, if it is, why not just show, instead of the message, a warning label that says: "This message's contents are very large. Displaying it may cause evolution to hang. [ display the message ]" And when rendering the message, a progress bar is shown.
Set to the default value of 4 MB(!) here. [x] Do not format text contents in messages if the text size exceeds 4096 KB Can reproduce the flickering with comparatativly small-ish messages. These flicker exactly once only, but they do flicker. Some examples, reproducible, with numbers: * 96 KB message, NO link or email address: Re-draws once, highly noticable. * ~23 KB message: Seems to re-draw once, really fast. * 1 KB message: No visible flicker, may just be too fast to be noticed. All these test cases are pure text/plain messages with a single MIME part. Even with messages that size, rendering flickers. This does not apply to the (pre)view pane only, adjusting Summary. Confirming. Cc'ing Srini, in case this indeed is related to the changes mentioned in comment 1.
(In reply to comment #6) > Yes, it does depend on mail size obviously. Large mail will flash. Feels like > it is being rendered more than once, in progressive chunks, or something. Right. If the flickering is long enough you can sometimes scroll to the bottom of the partially-rendered message and see more content get rendered with each redraw. Also, if the message is long enough, I've noticed the flickering slows down as more of the message is rendered (each iteration has more content to draw and thus takes longer). I suspect GtkHtml but much of that code is still an enigma to me...
Created attachment 110656 [details] Large commit log Another example - the svn-commits-list message from my "new composer" merge.
Ok. I saw that this is not a recent regression. I saw that 2.6 works fine and 2.8 onwards is broken and Im currently cherry-picking the patch that caused it, no clues yet. Will find it soon.
bug 528372 could be dup
Finally I picked the patch that caused it. Patch #67408 at bug #342659 caused it. WIth out that patch everything is cool.
Akhil, when I revert patch #67408 the mail you put or mbarnes's commit mails are rendered pretty fast than otherwise.
Created attachment 110835 [details] [review] Proposed patch
(In reply to comment #12) > Another example - the svn-commits-list message from my "new composer" merge. Nice, really annoying example, Matthew. :) Srini, tested the (reverting) patch, works for me. Nice catch. Even the ugly example by Matthew still takes a while being rendered, but there is NO visible re-drawing or flickering.
I can confirm that. While rendering I see the background colors swap between the header section and body section a few times (kind of hard to describe), but I'm inclined to believe it's a separate issue. Not sure if Srini was really looking for a patch review, but I'm approving the patch nonetheless since I think it's worth taking a temporary i18n regression to get rid of the damn flickering. (I still don't really understand how the original patch was causing the flickering, but I can live with the empirical results.)
Committed to stable/trunk