Honestly, it looks extremely weird that bold codes (or other color/underline/reverse ones) makes scrolling and receiving slower.
When a channel is being flooded with bolded text, and you haven't had stripped it, it completely freezes mIRC because it spends much cpu on displaying the texts.
Is there any chance that future versions will treat it more smoothly?
I think things would be a lot faster if mIRC didn't draw colours/codes while the window is scrolling, similar to some operating system GUIs having options to not draw windows as they are dragged and dropped.
The weird thing is that, there are no problems with regular text or other fonts, but only with bold...
I think it's because mIRC has to parse all the text to render individual letters as bold or colored etc. I dont know exactly how it's done, But i presume that mIRC counts the amount of codes, and then loops through the text, drawing them accordingly. Any control code would produce this problem, not just bold..
It looks like mIRC has much more difficulties with bold/underline than with color/reverse codes.
well this is D.O.S Exploit trick i seen flooder use with zombie bots "control code" flood cuaseing mirc to slow down and even crash whole o/s, that why strip codes option was added to mirc, i would advise enableing it
to limit the affect of this exlpoit attack
Yea, you're right. personally I strip all bolds, and probably that's what protection scripts do as well.
Although I know about the strip option, I think the mIRC needs to know how to protect itself.
Thats not really the problem, the problem is apparently the control used to draw the text isn't written as well as it should be, note if you use IE on a website with tons of graphics all over, and colored text all over, scrolling doesn't slow it down one bit. Keep in mind I'm not referring to some slow machine, I'm on a 1.4Ghz machine, mIRC is the only program that goes slow with colors all over. I also note that if I do the same in a standard Windows RichEdit control, it does not lag either. This means the problem isn't the system, nor the fact that there are a lot of color codes, the problem is the way mIRC handles them.
yes mirc redraes the whole text area when you scroll, while other programs BitBlt whatever is already visible, and only redraws the few lines which become visible. this could make mirc much faster, and in cases where it does not: make it an option so the user can choose.
another *option* which i'd like to see, is to not redraw/scroll for every added line, but after processing a block/packet/etc. for example a long MOTD or /WHO then does a few redraws, a /whois reply shows instantly.
Problem with stripping the codes. If you are teh op controlling the channel, you need to know when there are control codes to ban the flooder for it.
Its all fine and well when you avoid being killed coz u have the strip option on, but if you dont ban them because they are doing it.. it kinda loses the effect.