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?