Forums Bug Reports mIRC 6.31 is 17 times slower using draw commands

How it can be possible? I have prepared several tests, I have used them in two pcs, using Xp and Vista, with mIRC 6.3 and 6.31, and the conclusion is demolishing.

The numerical calculation test is basically equal in both mircs, slightly slower in the last as it has been normal in each new version of mIRC for years...

But the test using draw commands is tremendously slow with new mirc. With mIRC 6.3 one I obtain 5208 fps, and with 6.31 ... 307 fps.

How is possible? What justifies that slowness? The new icons? The new script editor? The new PNG library? Its a bug or is definitive?

In Vista also is slower, but not so slow, 2475 fps in 6.3 and 1658 fps in 6.31.

My script (IRcap) uses a graphical interface, and now I am doing simple games like the 8 Ball Pool and other that I have in project. That mIRC handles the graphics 17 times slower is a problem.

I hope that Khaled can remedy it for the next version. mIRC offers many possibilities that can give life at the IRC. But for some years, each new version of mIRC has been something slower than the previous one using graphics, over a 3% or 5%. Something comprehensible if every time includes more things. But this time, 17 times slower.. its a lot.

I think that Khaled must improve that aspect so that scripters can make things every time better, like more attractive graphical interfaces and, mainly, games, to play on line. Improvements in the graphics commands of mIRC, as for example vectorial graphics, like Flash style, would give many possibilities. And mainly more speed. I believe that those things must have priority for you, before icons changes, "messenger" modes, etc.

This is one of the test that I have used. Runs a loop during 10 seconds using /drawpic and says the frames per second at end. If you want to run it, need a "background.png" bitmap (400 x 400) and a little "sprite.bmp" bitmap with pure green color as transparent (rgb(0,255,0)).

alias testvel2 {
var %t = $ticks , %f = 0 , %n = 0 , %x = 0
window -kpBwz +d @testvel 100 100 400 300
drawpic -c
:L1
drawpic -cn @testvel 0 0 background.png
drawpic -cnt @testvel 65280 $int(%x) 1 0 0 160 16 sprite.bmp
drawline @testvel
inc %x 0.1 | if (%x > 400) { %x = 0 }
inc %f | if $calc($ticks - %t) < 10000 goto L1
echo -s Drawpic FPS: $int($calc(%f / 10))
window -c @testvel
}

Results in my PC (E6700):

In Xp, 5380 fps in mIRC 6.2, 5208 fps in mIRC 6.3 and 307 fps in mIRC 6.31.

In Vista, 2452 fps in mIRC 6.2, 2475 fps in mIRC 6.3 and 1658 fps in mIRC 6.31.


Thanks and sorry for my poor english.

The following is from a Vista machine:

Your benchmark is slightly inaccurate.

$ticks does not yield constant results; so your benchmark runs for a variable number of times-- meaning you very well could be measuring 6.3 doing less or more actual work than 6.31.

I modified the benchmark to render a *constant* number of frames but calculate the time variably, dividing the constant number of frames into time to get the fps:



I ran the test in three scenarios, to verify if the PNG lib might be responsible. One with (sprite.bmp,background.png), another with (sprite.bmp,sprite.bmp) and the last with (background.png,background.png), referring to the 2 images used as the sprite and the background image respectively. Here are the results:

sprite.bmp, background.png
6.31: Drawpic FPS: 1178.272652
6.3 : Drawpic FPS: 1540.832049
Diff: 23.5%

sprite.bmp, sprite.bmp
6.31: Drawpic FPS: 1366.680333
6.3 : Drawpic FPS: 1760.873393
Diff: 22.38%

background.png, background.png
6.31: Drawpic FPS: 1116.819299
6.3 : Drawpic FPS: 1541.069502
Diff: 27.5%

Conclusion:

I should first note here that the sprite.bmp and background.png files I used were different from yours. Granted, that should not affect the test in the global scheme of things but it does have effects on my specific resultset that change the way they should be intepreted.

My background.png was considerably larger than sprite.bmp. Therefore, the BMP only test was *expected* to be faster, and the PNG only test was *expected* to be slower. Instead, the PNG only test ran faster than the BMP/PNG test, meaning the PNG library actually improves performance. The BMP test is consistent with the speed improvement expected. While 6.31 is slightly slower, it's barely a factor of 1.3x.

It's important to note that when I was running tests, the first test would always be the fatest. Any further calls to the alias would be slower by nearly 40% until the window was deactivated and activated again. This happened on both 6.3 and 6.31.

I confirm that 6.31 is slower, but not by the amount you claim. The results are rather inconclusive due to the amount of fluxuation of the data I've seen, and nothing points to the PNG library being the problem. Perhaps custom window code was redone in 6.31?

I have tested both 6.3 and 6.31 with your test, and the results are practically the same: 5422 fps for 6.3 and 309 fsp for 6.31.

17.54 times slower...

mIRC 6.3 took about 2 seconds to complete test, and mIRC 6.31 33 seconds.

I think that the diferences are different depending the system. In my core 2 duo are 17 times slower, but in a 1.6 ghz pentium M, the fps was 533 for 6.3 and 236 for 6.31. 2.2 times slower.

In Vista the diferences are minor too. In Vista the fps was 2475 for 6.3 and 1685 for 6.31. mIRC 6.3 is 50% slower in Vista respect XP, and 6.31 is the opposite, 5 times faster in Vista than XP (but always slower than 6.3 in XP and Vista). Curious.

In my example I used bitmaps from my pool game, the background is a bitmap of 450x248, and the sprites are the balls, 272x16.
I have tested the background in bmp and png format with the same result.

About PNG library, I think that mIRC, once time the bitmap, in every format, is loaded, cached and maped in RAM, the format doesn't matter, its a block of memory.

So, for me, mIRC 6.31 is 17 times slower in my core 2 duo, 2.2 times slower in mi Pentium mobile. In a medium 2 ghz pc perhaps is 2 or 3 times slower, a lot for a version with a few changes and bugs fixed.

The only change that I can think of that might cause this is item 20 in 6.31 versions.txt file: Fixed $inellipse() bug by enabling floating point consistency option in compiler.

In my tests, this change made mIRC slower by a small amount on the systems that I use. However, it may be that since this method of ensuring floating point consistency is memory intensive, the speed decrease will vary depending on your system compononents.

I implemented this change to ensure that the same issue that affected the $inellipse() routines (a compiler issue) would not affect any other routines in mIRC. However since it has had a significant impact, I will roll it back and apply a fix only to the $inellipse() routine.

When will this fix be released? This problem slows down my game fps rates making it difficult to play properly.

As always, it will be released when it is released. No date will ever be given in advance. Don't expect it anytime soon, though. A release isn't going to be made for one item and it takes time to test all new features, changes, and bug fixes in a program to avoid other possible issues.

Im having to use an older version at the moment

I hope this will be fixed, and I hope too that next mIRC version will be more faster than previous, because is a frustration to download every new version and see how is a 5% (+ or -) slower, how the script gui is slower, how the fps in games are lower, etc.

if you have fps problems, try disabling some of the features if possible, use drawcopy instead of redrawing the same thing over and over, and use less detail.. also, dont use to many aliases for simple things like math problems etc. because it takees time to locate and use those aliases

In my pool game, redraw background is faster than copy the background for the 16 sprites, I have tested it. Using a few draw commands to draw big graphics are faster than using a lot of code to draw more little graphics, because the scripting language are very slow. If you are using assembler you can do it, but not in mIRC.

There isn't detail to use less only 16 sprites and background.. and there are only a few aliases in the game bucle.

There are a way to make the game 17 times faster... by using mIRC 6.2 instead 6.31.

there are ways to make fast games, but u just gotta know.. they will never be as fast as a compiler but

also the drawrot command in 6.31 does not work correctly when using transparency

i know this becuse i tested it in 6.2 and it worked correctly

^^ it's not recognising the transparency

how did you use transparency with /drawrot ? The -t isn't specified in the help file.

the -b

It's not transparency, the -b switch only "indicates that you've specified the background color value"

i know.. but its basicly saying that the color of the background should be white and then when it's copied back over it will be transparent
but that doesnt work

heres an example: test in mIRC 6.2 and 6.31
http://www.mediafire.com/?gec3cgq4mbc

Thanks the /drawrot -b bug has been fixed for the next version.

thx, and i wasn't sure if it was a drawrot or a drawcopy error, but its fixed :P

I have managed to track down this issue. It is not due to the floating point consistency change that I referred to in my previous post. The reason for the decrease in display speed is a change I made relating to this bug report.

For many years, users reported that mIRC would stop displaying background pictures in windows if they opened too many windows. It turns out that this was because, for some users, mIRC was loading bitmaps into video card memory (this depended on the type of video card and the video drivers). This also prevented some users from playing full screen games while mIRC was running.

I changed the bitmap loading method in mIRC 6.31 so that it no longer used video card memory (or at least, tried to avoid it). This resolved the background picture issue. However, it has clearly had an effect on display speed. Another user has also reported that 6.31 now uses too much normal memory - but if you are going to use background pictures, the memory has to come from somewhere :-]

One way to resolve the /drawpic speed issue is to make it use the old bitmap loading method, while ensuring that normal background pictures continue to use the new method. I am currently looking into this.

im not sure about this, or if u already did this, but you could try making mIRC save the file name to a var and have mirc find it and send it to the video card to process it

Uh... what would that solve?

speed

The images are already stored in memory, the decision is whether they should be stored in system memory (RAM) or video memory (the video card's on-board memory). Storing the image on disk (which is what I think you're suggesting) would be several orders of magnitude slower.

mIRC stores to the RAM(im no good with hardware and internal processes)

So if you're no good with hardware or internal processes then why are you attempting to have a discussion about the benefits of using a GPU's processor for speed?

why do u care?

and im not bad with them.. and i asked someone about it.. so, why not

The point is that if you don't know what's going on, offering suggestions just wastes time. Putting a filename in a variable is not going to offer a speed difference. The issue is almost entirely CPU vs GPU. And Khaled already said what he was going to attempt, so that should really end discussion unless someone has a suggestion regarding how to implement what he plans or else knows of some issue that will come up using the method he's going to attempt.

I noticed at one time that after running for a while, 6.31 seemed to be a bit sluggish, so after reading this thread I wanted to see if there was a difference between 6.3 and 6.31, even though I never use background images. On one of my slower machines, I ran 6.3 on four large and busy channels with lots of control codes for an hour. I then ran 6.31 on the same four channels for an hour and there was a very noticable difference in response, 6.31 being very sluggish to respond after the hour. The machine was rebooted before each test and both were clean with no background images. So this change effected display speed regardless of whether or not there is a background image.

Sluggish in what way? I run mIRC 24/7 for weeks or months without restarting it or rebooting my computer. I do have a good machine, so that may be why it works fine here. I'd still like to see what you mean by sluggish, though.

whats ur buffer (lines) limit

that affects it too

also, im thinking that the visual effects have some effect on this, but im not sure

As do I, but I noticed a few times on one of them that after running 6.31 for a few days, it was sluggish. After reading over this thread, I wondered if that was my problem too so I decided to test it against 6.3. That machine is a AMD Athlon 64 X2 4200+ with 2GB DDR2 RAM, so I figured it would take too long to get 6.31 back to the sluggish point so I tested it on one of the older systems which is AMD Athlon XP 1800+ with 1GB DDR RAM and after an hour, the difference between 6.3 and 6.31 was very noticeable. The system specs really are irrelevant, the point is that there is a major difference in the display speeds between the two versions, regardless of the system.


The buffer was at 1000, but again, that's irrelevant because they were both tested under the same settings, system and circumstances and there was a very noticeable difference between the two versions.

~ Edit ~
Sorry, OS is XP Pro SP2.

I know the dictionary definition of sluggish, but that doesn't in any way show how *mIRC* is acting so that others can understand and test it.

The UI is slow to respond when I click on a switchbar button for example. Popup menu's are slow. Window text is slow when I type something and hit enter. Just sluggish in general. It's not really near as bad here as the OP described, but still a noticeable difference between the two versions.

ive noticed it too... and yes, like i said, its probably the visual fx

Can't reproduce anything like that here... even at weeks of use. Granted, like I said, my computer isn't slow. I haven't run mIRC 6.3x on anything slower than what I have now (AMD64 X2 6000+ w/ 2GB DDR2 800 RAM). So it's quite possible that what you describe just isn't noticeable on this computer.

I'd suggest checking your memory usage of mIRC after that period of time, though. I run mIRC with Invision installed (and that's a pretty heavy memory-use script) at around 12MB. mIRC without Invision (just a bot with trivia, weather, dictionary) runs at 9MB. If you are getting a lot more memory use than that, then the problem may be related to something else (DLL, script, etc). It would at least help narrow your issue down.

I think you're somehow missing my point. I intentionally did the tests on a slower machine. Both had no loaded scripts nor dll's. Both had no background images. No other programs running. Both sitting idle on the same four very busy channels with lots of colors (yes mp3 channels), both on the same machine, both using the same mirc.ini (same exact settings). In those conditions, 6.31 was a lot more sluggish after the hour was up than 6.3 was. System specs are irrelevant when the two different versions were measured under the exact same conditions. Granted, you're running a dual core, 64 bit, 3GHz processor with 2GB PC6400 RAM so no, you may not notice it. I barely noticed it on my dual core, 64 bit, 2.20GHz processor with 2GB PC6400 RAM, but I noticed it enough to to make me want to test it on an older, slower machine where it was WAY noticeable.

~ Edit ~
Have any of you guys tried SeaMonkey? After using this for the past week, Firefox (Bloatware) sucks. I'm really impressed with it. You should try it.

I've been using a P4 3.2Ghz with 3GB RAM running XPSP2 (mIRC with 30000 line buffers in 40+ channels, most fairly busy), and haven't noticed any sluggishness.

.. So, odd ..

You still didn't mention your memory usage. There can be specific reasons for mIRC to run more slowly over time (with any computer) when switching between older mIRC versions and newer. Changes to how various scripting issues are handled is just one of those reasons. If your mIRC is using excessive memory after a few days (20+MB), then there's another problem.

Well I didn't test for memory usage, because the whole point of my reply, was that there was a significant difference in display speed when the two different versions were tested under the exact same conditions. Khaled himself stated earlier in this thread that he had made a change in 6.31 that "clearly had an effect on display speed" so why are we still going on and on about this?

~ Edit ~

Although system specs in this test were irrelevant, I do have a P4 3.2GHz machine with 2GB PC3200 RAM, I'll try and do the same test on that machine later. As I said to Riamus2 earlier, you may not notice something like that, it was barely noticeable to me on the machine I noticed it on, but I notice things like that because it drives me crazy. I noticed a little difference in response after it had been running for a couple days so after reading this thread I wanted to test it against 6.3 on an older/slower machine and there it was very noticeable. I notice things like this like you would notice a fly on your nose, which is also why I reinstall the OS every few months.

And the point I was making is that there are other changes in mIRC that can cause slowdown issues from one version to another. If you have excessive memory use, then it would narrow down the problem. I don't see why it's such a problem to state the memory usage.

Unless I've missed it somewhere in your posts, you haven't said anywhere why you think this is linked to the bug in this report. You said you're not using any background images, so are you using picwins? If not, it's very possible it's unrelated to this bug. If your memory usage is the same then it almost certainly is unrelated, in which case it probably deserves its own thread.

Assuming it isn't related to the image issue all I can say is that it definitely isn't a problem for everyone. I've got a couple of very mediocre systems that show no slowdown after hours or days of running.

The only reason I even got involved with this thread was because Khaled said this...



... which made me think that maybe it was related. My reply was to Khaled, not Riamus2 or foshizzle or anyone else. Maybe he should clarify whether he meant display in general or picwins only.

in general

And again you dodge the question.

lol

why do u have to be so serious

Man wtf is up with you? I said earlier that I didn't check the memory usage after each test. I'm not dodging anything. I don't have an answer for you. Do you want me to take a polygraph test? Do you think I'm conspiring something? If you look carefully at this reply above, you can clearly see where I stated...



I know there will be differences between versions, but this is a comparison of 6.3 and 6.31, not 5.9 and 6.31.