439248 - Background async actions like deletes & moves need to seem faster to the user - too much spinball, etc

Status: NEW

(Thunderbird :: Mail Window Front End, defect)

Description

[David Ascher (:davida)]

The async delete is much faster than the previous synchronous delete.  However, it still feels slower than in mail.app, and I think that's because there is various UI activity that track the actual deletion -- status bar messages, cursor changes to arrow+spinball, etc.  I think that background activities should be completely invisible except for explicit checking of activity logs.

Thoughts?

Comment 1

[David :Bienvenu]

the cursor and arrow+spinball have more to do with loading the next message than they do with tracking the delete. If we had pre-downloaded the messages for offline use, you would be a lot less likely to see those happen, since loading the message would be a lot faster. We only start the spinball if the operation takes over a certain amount of time (maybe .5 seconds?). We could increase that time. I'm fine with getting rid of the arrow and spinball as much as possible (especially the spinball which I think is a cpu hog). I'm less excited about getting rid of the status bar message since I think it's useful feedback, especially if the operation does take a long time, for some reason. We could easily not display the status message, however, by just not passing in the msgWindow to the offline playback operation object.

Comment 2

[Bryan Clark (DevTools PM) [:clarkbw]]

I think the key to the perception of slow is placing blame (of slowness) where it needs to be.  For the case of a message not already offline we just spin and wait causing people to think that Thunderbird is inherently slow instead of thinking that downloading all their mail all the time is slow.  We should be rendering as much of the message as we have, like the header, and then place a "Downloading Message" area below that with a spinner or progress meter.  This moves the idea of slow from Thunderbird in general to the internet connection.

Without even trying to optimize load times we really need to start placing blame (or fame) where it belongs and we'll be perceived to be much faster.

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

clarkbw: That seems reasonable; are you suggesting that doing such things in addition to or instead of the initial suggestion in this bug?

Comment 4

[Bryan Clark (DevTools PM) [:clarkbw]]

I'd suggest in addition to.  Suggestions from comment 1 seems fairly quick and easy to get done, while my suggestion will take some reworking of the message reader.

Comment 5

[Wayne Mery (:wsmwk)]

(should this be OS=ALL?)

does async DL imply the next message is already in memory?  If not, how about precharging memory with next message (read or unread depending on the user's view or current pattern) during idle?

irrc there is a bug on spinball being cpu hog

Comment 6

[David :Bienvenu]

async DL means the next message is most likely on disk locally, which means displaying it is much faster than getting it from the server. Getting rid of or delaying the spinner even more would be a good idea. Having hints for autosync about what a good next set of messages to download would be a nice idea.

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to David :Bienvenu from comment #1)
> We only start the spinball if the
> operation takes over a certain amount of time (maybe .5 seconds?). We could
> increase that time. I'm fine with getting rid of the arrow and spinball as
> much as possible (especially the spinball which I think is a cpu hog). 

Not sure how much has changed in the intervening 4 years. But IMO delaying and/or eliminating spin and progress meter may still help. 

Furthermore, going a touch beyond what comment 0 is about, there is (or at least was ... testing is needed to reconfirm) a *real* CPU cost to progressmeter (bug 562977). Extrapolating the effect of CPU contention from non-Thunderbird processes, even a little progressmeter CPU usage noticeably affects the speed of loading next message.  Furthermore, laptops whose disks tend to be slow take the perf hit for longer time.  (I don't know about spinball - don't have a Mac, and didn't find a bug report about it)   

perhaps there is also impact from bug 308158?


(In reply to Bryan Clark (Firefox Search PM) [:clarkbw] from comment #2)
> I think the key to the perception of slow is placing blame (of slowness)
> where it needs to be.  For the case of a message not already offline we just
> spin and wait causing people to think that Thunderbird is inherently slow
> instead of thinking that downloading all their mail all the time is slow. 
> We should be rendering as much of the message as we have, like the header,
> and then place a "Downloading Message" area below that with a spinner or
> progress meter.  This moves the idea of slow from Thunderbird in general to
> the internet connection.

Do we have such a bug?

I don't find a bug about incremental rendering of message. The closest is bug 537940.

Comment 8

[Josiah Bruner [:jsbruner]]

(In reply to Wayne Mery (:wsmwk) from comment #5)
> (should this be OS=ALL?)
> 
> does async DL imply the next message is already in memory?  If not, how
> about precharging memory with next message (read or unread depending on the
> user's view or current pattern) during idle?
> 
> irrc there is a bug on spinball being cpu hog

Note that the spinball should not be impacting performance at all. It doesn't work in a way that would cause serious issues. It definitely makes the user believe things are slower though. 

also, keep in mind that the "blue" spinball we're using can be removed, but the colored one cannot (The colored one happens when the CPU is being used excessively.

Everything I just mentioned concerns OS X only.