thunderbitd delayed message loading using keyboard
Hi, when browsing through messages in a TB folder it shoes the message content immediately when selected by mouse, but when I use up or down key there is a long delay before the message is loaded. It makes it unusable when searching for something and very annoying in general. It looks like a bug because the cpu use is 0, so it certainly just waits for no reason, but in case it is a "feature" I want to know how to remove that delay.
Modified
Chosen solution
The use case I outlined isn't about saving CPU, it's about speed of user navigation. So I don't expect this to change.
You can help your use case by changing the value of mailnews.threadpane_select_delay which defaults to 250ms
Read this answer in context 👍 1All Replies (11)
This is difficult to address remotely. If a POP account, the activity relates to disc speed; if IMAP, there is of course the network. Two options I can think of: under server>advanced, you can increase connections, which may help for IMAP. There is also the Synchronizations section where you can check to have folders downloaded, which should minimize scrolling delays. I am no expert on this topic, but I hope this info may help.
the connection type does not matter the message is stored locally. Disk speed is about 2GB/sec express line ssd so that is definitely not a bottleneck :-). And it works fine with mouse events so it looks like an UI problem. I can capture a video.
I press down than nothing happens for a second and then it shows loading message in notification are and shows it in the message pane. When I click in the same message by mouse it does loading immediately. Those are simple plain text messages about 1kB so no html or anything.
also its a recent clean install win 10 64 bit, so all setting should be default
Test for the effect of startup apps such as antivirus etc. by running Windows in safe mode.
Safe mode does not help and bunch of other stuff does not work there.
to make it clear, I made a 30fps video with clean windows and only latest TB installed. Few email on local folder and it still has the same exact lag. All data is in local folder. You can also see the process monitor showing almost 0 CPU or disk.
looks like i cannot attach it so get it from here https://drive.google.com/file/d/1l8I1ZJaVACz1XmuImLG4WTyRAvpxyaNP/view?usp=sharing and download the original file, not the youtube coveted version.
1st part is random clicking on emails, despite I can not click very fast you can see there is no delay between selection and message being shown. 2nd part is moving by up/down arrow keys and you can clearly see that there is at least half second delay between line selection and correct message being shown on right side. In fact it is so slow that the middle message is not shown at all.
The PC can render 100+ frame per second in video games don't tell me its too slow slow TB :-) I am 99% sure it is a bad design somewhere in UI waiting on some stupid timer :-(. Just run it in VM and you will se the same lag.
IIRC the delay is intentional, and desired.
This because if you hold down the arrow key a few seconds until you get to your desired destination, you don't want all message displays in the middle to display because it would slow up getting to the eventual desired message.
The delay makes that process work correctly, but causes the display delay you are seeing when somewhat slowly arrrowing though the messages.
Conversely, if you use F or B key to step through messages, you will not see a display delay.
Modified
Hi Mery, tried tried F B and it does indeed show the content immediately.
Chosen Solution
The use case I outlined isn't about saving CPU, it's about speed of user navigation. So I don't expect this to change.
You can help your use case by changing the value of mailnews.threadpane_select_delay which defaults to 250ms
Modified
Hi Mery
With with key repeat 30/sec only 2 out of 100 messages created a slight delay because of 10MB png attachment. I did not consider that to be an issue, but if you trying to avoid that I see your point.
threadpane_select_delay = 0 is the solution form me. It it snappy and woks perfectly.
Happy to help.
I'll make the observation that this delay would be more relevant for users who don't have messages stored locally. But, locally synced is the default since version 3 circa 2009. It perhaps would be nice if this workflow took that into account, i.e. impose the delay only when messages are not local.