Whilst the timings here are interesting, the important things for me are:
1. During normal usage, messages are not noticeably delayed. I doubt I would notice a delay of 1ms or 5ms or even 10ms but I would almost certainly notice a delay of 100ms.
2. During these excessive bursts of messages trying to update the screen frequently, mIRC locks up because it is using all the CPU it can get (often a whole core on multi-core systems) to update the screen and a queue of actions builds up internally and my interactive activities get sent to the back of the queue and are not done in a timely manner (and even when they are done, the output responses may be queued behind another load of screen updates).
Two possible methods can be used to resolve this.
a. mIRC maintains two queues of activities to process, and handles interactive actions and their responses as a priority. However mIRC internals may make this difficult to do, and handling responses to interactive actions as a priority may be difficult to distinguish from other outputs. Nevertheless if this is achievable it might still be useful for when fupdate isn't handling things.
b. You avoid queues of output actions building up by grouping them so you do the screen updates only every x ms thus lowering the CPU overhead of displaying them and keeping CPU load to the point that queues do not build up. This is my understanding of how fupdate works.
The key point, however, is that during these burst of activities my primary need is for mIRC to keep pace with the messages and stay responsive and not that messages are displayed promptly - after all if the messages are coming in this fast I am not going to be able to read them.
So whilst I welcome the new fupdate, and whilst it might well do the job when floods of messages come in, it may not be the best algorithm.
Personally I would start with having a default fupdate value which reflects how fast the human eye can see changes. If we have 200 messages come in at one per ms, am not sure I can tell the difference between the screen scrolling one line every ms and scrolling 10 lines every 10ms, but I would probably see the difference with fupdate at 100 if it scrolled in two lots of 100 lines.
So the fupdate value should probably be the minimum delay time that applies all the time in order to keep CPU down.
Then we would want it to ramp up NOT based on how many messages have been received but by whether mIRC is getting enough CPU to keep pace i.e. by whether the we are actually getting sufficient CPU to process the messages every x ms which might be the same as comparing how long it took us to process this set of messages to the fupdate time period. If we took too long this time, we could ramp up by doubling the fupdate period; if we handled it within the ramped up fupdate period then we can reduce it to $max(fupdate setting, $ceil(elapsed time for the current display * 2)).
Apologies for the long post but I hope this helps with finding the best algorithm.
