mIRC Home    About    Download    Register    News    Help

Print Thread
#213868 10/07/09 05:16 PM
Joined: Oct 2003
Posts: 110
D
Vogon poet
OP Offline
Vogon poet
D
Joined: Oct 2003
Posts: 110
This is more or less a thread to point out at issues that seem to affect redraw and responsivity of mirc under both windows 7 and windows vista.

References:
https://forums.mirc.com/ubbthreads.php?ubb=showflat&Number=211978&page=1#Post211978
https://forums.mirc.com/ubbthreads.php?ubb=showflat&Number=209146&page=0#Post209146

It seems that in general redraw under vista and win7 is multiple orders of magnitude slower than under XP.

A good experience to test that is to open 50 windows, cascade them, and then try to minimize them all by staying pressed on ESC.

Under vista/win7 I can see 2-3 windows lowered every second(~20 seconds to minimize them all), whereas on XP it barely takes 1/4th of that time to do the same.

Those responsivity issues seem to often create stockpiling of gdi redraws, which greatly affect MDI usage(aero or not, since aero does not manage MDI).

Under win7 newer issues appeared, for example the typing lag.(start typing, and you can see the cursor go forward, but the input bar stay clean, sometimes it never even redraws properly)

I am guessing microsoft is to blame, but would like to hear khaled's opinion on the matter.



Note: this happens in vanilla mirc under both x32 and x64, on a variety of platforms. I can only say I have been seeing it with the multirow tabbar open, but I have not extensively tested without it.


Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
How are you testing XP/Vista timings? Are you dual booting? Using a virtual machine? Different computers? I can only hope you're taking into account any hardware or cpu usage differences between the two, if you're not dual booting.

It took 5 seconds to minimize (with ESC) 50 windows on my Vista64 machine. I've never noticed any mIRC-related performance issues with Vista before in the 2+ years I've been using it, so I'm skeptical about these claims.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Oct 2003
Posts: 110
D
Vogon poet
OP Offline
Vogon poet
D
Joined: Oct 2003
Posts: 110
same machine, two drives of the same brand and series, one with vista one with XP.
all updated to latest drivers.
I've seen the problem on my laptop too(which is dual boot)

I'd like to point the slow minimizing occurs a lot slower when the buffers have actual content.

One thing to try too might be to disable aero, since aero could possibly be skipping redraws with the double buffer.

(in my case win classic theme with no aero)

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
With Aero off it took roughly 5 seconds as well. My buffers, however, were empty. Of course it wouldn't surprise me if minimizing full buffers would take longer than 5 seconds.

Why don't we isolate variables here: Do not use full buffers to test in either XP or Vista.

Code:
//var %i = 1 | while (%i <= 50) { query x $+ %i | inc %i }


Use the above code, cascade the windows and press escape. Time the results under both OS's and report.

Then, if you're curious, you can repeat for full buffers, but of course it will be slower. What we're interested in is the empty window baseline times.

Now, given that GDI under Vista is NOT hardware accelerated (in XP it was), you should expect it to be slower. Slower by how much depends on the scenario, but if there's more content to redraw (in the buffers) then it seems perfectly reasonable to me that 5 seconds can turn into 20 if every one of those 50 windows is full of data.

Windows 7, however, should be hardware accelerating GDI, so there shouldn't be an issue in Win7 (of course it should still take longer than 5 seconds). How are you testing Windows 7?

On a sidenote, I'm just wondering, do you think mIRC is responsible for any of this behaviour? If not, why file a bug report? It seems quite obvious (at least to me) that this is unlikely an issue with mIRC but rather one with GDI.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
I just re-tested this 50 windows full of 1000 lines of buffer data each:

Code:
alias fill_windows {
  var %num = $iif($1, $1, 50)
  var %i = 1
  while (%i <= %num) {
    var %x = 1, %n = x $+ %i
    query %n
    while (%x <= 1000) {
      echo %n $str(x,100)
      inc %x
    }
    inc %i
  }
}


Each window has ~100kb making a total of 5mb of data. If this isn't representative of your 50 windows, nothing is. Note that the command takes ~30-45 seconds to load.

Results: roughly the same time in Vista, 6-7 seconds (instead of ~5).

I guess that sort of shocks me, I expected it to be slower. Of course, in the context of this discussion, that leaves me even more skeptical of your results.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Oct 2003
Posts: 110
D
Vogon poet
OP Offline
Vogon poet
D
Joined: Oct 2003
Posts: 110
I'm currently testing fill_windows, and it seems to be taking a good 10-20s for each window
EDIT:please note that I'm using the win classic theme(so no dwm or aero afaik)

EDIT2: okay, fill_windows took 3mins20s of cpu time to finish.

EDIT3: esc minimizing takes 9-10s

Last edited by DeathWolf; 13/07/09 01:04 AM.
Joined: Oct 2003
Posts: 110
D
Vogon poet
OP Offline
Vogon poet
D
Joined: Oct 2003
Posts: 110
Originally Posted By: argv0
Windows 7, however, should be hardware accelerating GDI, so there shouldn't be an issue in Win7 (of course it should still take longer than 5 seconds). How are you testing Windows 7?

It seemed to me they didnt change anything on gdi draw in win7(it stayed fully software as in vista). All that is accelerated is buffering of windows because of dwm(like in vista) and some form of threaded rendering, but I could be wrong.

Originally Posted By: argv0
On a sidenote, I'm just wondering, do you think mIRC is responsible for any of this behaviour? If not, why file a bug report? It seems quite obvious (at least to me) that this is unlikely an issue with mIRC but rather one with GDI.

Because this could possibly be solved by some workaround in mirc if it's indeed a major windows flaw(some extremely slow codepath maybe? for all I know it could be many things)

Joined: Oct 2003
Posts: 110
D
Vogon poet
OP Offline
Vogon poet
D
Joined: Oct 2003
Posts: 110
mmm, I just tried with aero and dwm on, and full acceleration and it took 2:50 to fill_windows, which is not that slower.

ESC-minimizing took 7s. which is not that slower either(than with acceleration).

I will need to test on XP though for gdi accelerated rendering.

So my reasonning of blaming mdi&gdi might have been wrong.

I am still experience massive freeze spikes(10-15s long sometimes) quite often though, and those dont seem to be justified in any way.(all I have figured about those is that they dont seem network activity bound(no netsplit/quit/join messages when they occur, but that on the other hand they seem very common when typing text, maybe some ime issue?)

Joined: Aug 2004
Posts: 7,252
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Aug 2004
Posts: 7,252
If you are noticing these "freeze ups" while you are typing, do you have one or more scripts that uses the ON INPUT event?

Having an older, slower machine, I avoid that type of script like the plague.
The time required to process an ON INPUT event, (one of the few times I tried using a themed script), ended up showing my message a good 5-10 seconds after I had typed it. Way too long for a conversation.

Joined: Oct 2003
Posts: 110
D
Vogon poet
OP Offline
Vogon poet
D
Joined: Oct 2003
Posts: 110
I only have one on input that I wrote myself, I have now disabled it but it seems to make no difference.(Plus didnt it just act once you send the message? my freezes occur while typing in general)

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Do you have any timers running or are you using a bouncer to connect to your networks?

mIRC periodically "does stuff" on each connection, so do timers and bnc's-- if all your connections were initiated at the same time, they will all "do stuff" at those periodic times, potentially causing significant delay if what they're doing is resource intensive. There have been previous reports that psyBNC caused periodic freezing when connected to multiple networks because of data intensive commands it periodically sent to servers.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Dec 2008
Posts: 1,515
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2008
Posts: 1,515
Originally Posted By: argv0
I just re-tested this 50 windows full of 1000 lines of buffer data each:

Code:
alias fill_windows {
  var %num = $iif($1, $1, 50)
  var %i = 1
  while (%i <= %num) {
    var %x = 1, %n = x $+ %i
    query %n
    while (%x <= 1000) {
      echo %n $str(x,100)
      inc %x
    }
    inc %i
  }
}


Each window has ~100kb making a total of 5mb of data. If this isn't representative of your 50 windows, nothing is. Note that the command takes ~30-45 seconds to load.

Results: roughly the same time in Vista, 6-7 seconds (instead of ~5).

I guess that sort of shocks me, I expected it to be slower. Of course, in the context of this discussion, that leaves me even more skeptical of your results.


LOL, I tryied this code too and my mIRC stucks after 5 seconds omg! , and when i used CTRL+break crashed!

EDIT: I changed the while (%x <= 1000) with 100 and took me about 1 minute and some seconds

Last edited by westor; 13/07/09 10:03 PM.

Need Online mIRC help or an mIRC Scripting Freelancer? -> https://irc.chathub.org <-
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
And the point of this post was?


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Dec 2008
Posts: 1,515
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2008
Posts: 1,515
The point of this post was to see that your code was for the rubbish and made my mIRC to stuck and crash.


Need Online mIRC help or an mIRC Scripting Freelancer? -> https://irc.chathub.org <-
Joined: Oct 2003
Posts: 110
D
Vogon poet
OP Offline
Vogon poet
D
Joined: Oct 2003
Posts: 110
Originally Posted By: argv0
Do you have any timers running or are you using a bouncer to connect to your networks?

mIRC periodically "does stuff" on each connection, so do timers and bnc's-- if all your connections were initiated at the same time, they will all "do stuff" at those periodic times, potentially causing significant delay if what they're doing is resource intensive. There have been previous reports that psyBNC caused periodic freezing when connected to multiple networks because of data intensive commands it periodically sent to servers.


Yes, bouncer. I tried desynching the connects, but without much success so far.(still a lot of cpu usage and freezing).

Overall the freezing does seem global activity linked, at times of the day where most people are not talking responsivity is fairly good, but it is much worse at evening when everyone's talking.

One thing that might matter is that there's a non negligible amount of tcp retransmission on my DSL line, and I'm wondering if that could be causing some extreme race condition here and there.

Joined: Oct 2003
Posts: 110
D
Vogon poet
OP Offline
Vogon poet
D
Joined: Oct 2003
Posts: 110
as one more hint, maybe an unrelated/separate problem, that a few other users confirmed to me:
switching to mirc from another application can/often yields a long(few seconds) wait before mirc becomes responsive, once in, thins are much better.
And for users alt/win+tab'ing a lot things can get excruciatingly slow...

Last edited by DeathWolf; 19/07/09 03:33 PM.
Joined: Oct 2003
Posts: 110
D
Vogon poet
OP Offline
Vogon poet
D
Joined: Oct 2003
Posts: 110
And to add to this issue, I would like to point to those that might have the issue that changing mirc's affinity to a single cpu has strangely been reducing a lot the issue.
(not completly, but enough to make things more usable)


Link Copied to Clipboard