mIRC Home    About    Download    Register    News    Help

Print Thread
Page 2 of 2 1 2
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
That looks right to me. It ramps up quickly. The more lines that are printed to a window in a certain amount of time, the less often it updates the window. Are you asking for it to respond less quickly? For example, to not react at all for a certain number of messages? This will make it initially slow to react to bursts of messages.

Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Yes, that is what I was meaning. That /fupdate should perhaps not be so aggressive initially. My request is intended for mitigating large scale scrolling slow-down, but not for a small dozen or so lines of ascii art. mIRC becomes unresponsive after 50 or 100 lines of nonstop scrolling, which is where /fupdate really helps out.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
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.

Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
The new beta changed everything and has not yet been commented on in this thread. The current beta is now v7.51.2148 not 24 hours old yet.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for your comments.

The main focus of the first implementation of this feature was to minimize lag in the user interface the more messages were printed in mIRC across all windows. It did this by progressively decreasing the display update rate, so as more lines were printed, it would delay the display update to every Nth line, where N would gradually increase.

One reason why I implemented it this way is that it is as independent as possible from how slow/fast the user's computer is. It just kicks in and ramps up.

The second implemention, in the latest beta, changes the algorithm so that:

(1) it calculates the maximum lines per second dynamically - it gradually increases the display update delay until any further delay makes little difference and leaves it at that level. So, for example, if you set a /timer to echo at 250ms, it won't trigger /fupdate. At 10ms, it will. If the timer then changes back to 250ms, /fupdate adjusts automatically. So /fupdate now tries to display text as smoothly as possible based on the lines per second being printed.

(2) Any speed less than 10 lines per second no longer triggers /fupdate.

Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
I have downloaded and tried the new beta. And it definitely works. Here is my test:

Quote:
//window -ae @test | var %j = 0, %s | while (%j <= 20) { .fupdate %j | var %i = 1, %n = 1000, %t = $ticks | while (%i < %n) { echo $calc(%i % 100) @test %i $str(X,100) | inc %i } | var %m = $calc($ticks - %t), %s = %s $+(%j,:,%m) | echo 4 -a done. fupdate= %j in %m ms. | inc %j } | echo 13 -a DONE. (fupdate:millisec) %s


Quote:
(fupdate:millisec) 0:3250 1:1875 2:1485 3:1219 4:1093 5:1000 6:891 7:828 8:781 9:703 10:687 11:672 12:656 13:625 14:578 15:563 16:562 17:547 18:532 19:546 20:500


Law of diminishing returns suggests that with the latest update an fupdate of 10 is a good setting - and since I doubt you will see any delay at 10ms, a default of /fupdate 10 might be ok.

That said...

I am unclear what impact the fupdate setting has on the algorithm just described by Khaled.

Additionally, without some sort of server driven flood test running mIRC on a low powered CPU, I have no idea whether this would stop mIRC locking up in such situations.

Last edited by Protopia; 04/02/18 01:49 PM.
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
I am unclear what impact the fupdate setting has on the algorithm just described by Khaled.

The /fupdate setting is the maximum display update delay. So if you specify 100, it will display less frequently than 10. That said, with the latest algorithm, even if you specify 100, it may not reach that since it is adjusting automatically to the maximum value that makes a significant difference.

Quote:
Additionally, without some sort of server driven flood test running mIRC on a low powered CPU, I have no idea whether this would stop mIRC locking up in such situations.

This is the main issue with the new method. For example, 10 lines per second may cause UI lag on a slow computer, so the value should be lower for slow computers so that /fupdate kicks in earlier. But the only way to know this is to benchmark the computer.

Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Requesting a followup on the development and deployment of /fupdate. So far, I and a lot of people are loving the new behavior. I still don't claim to entirely grasp the algorithm, nor whether it can/should be improved upon, I would like to see it eventually become a default behavior that users don't have to turn on or script for.

At the same time, the 'smooth scrolling' feature might also be removed as obsolete if /fupdate, with its sliding intensity, can address those issues at the same time. I do think there is enough of a discrepancy between /fupdate 1 and /fupdate 100, it could perhaps use some improvement to negate the need for a number all together, even if this involves nesting of sliders.

I'm instructing a lot of people to put ON *:START: FUPDATE 100 in their remotes.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Page 2 of 2 1 2

Link Copied to Clipboard