Doing a recent testing with nightly 2002091208 showed that we do considerably slower on the testcase. I already tun the testcase sometime ago: trunk 2002091208 | trunk 2002052008 | msie6 | opera6.0 | ns4.78 --------------------------------------------------------------- 8492 | 4957 | 1502 | 1502 | 3715 Test-workstation has 1.1ghz, 512ram, 32mb geforce2 go Maybe bug 157144 might have an impact on the slowdown?

On my Celeron 1,06GHz, Intel 830M, WinXP, trunk build 2002091908 it isn't that slow, but don't know the exact number as it doesn't give me the dialog. But then again this build includes fix for bug 157144.

More tests: Mozilla 1.0 | Mozilla 1.1a | Mozilla 1.1b ---------------------------------------------------- 7080 | 7070 | 2884

Here are more tests On an Athlon 1333 512 DDR Nvidia TNT2 with Linux 2002091804 | | ------------------------------------------ 2575 | | On a Imac PowerPC G3 233 192 RAM Mozilla 1.0 | | ---------------------------- 54830 | | And mozilla on Mac is really slow :)

Attinasi is gone - reassigning to dbaron

on linux, the testcase runs about the same with 1.0 through current trunk 7500 +/- 500 ms. tested on 450 MHz P-II, RIVA TNT (16MB)

Here we go again. On my work machine (Athlon XP 2200+, 512MB, G550) it gets much faster when I change color depth. No matter if I change it up or down. I think this is the same as http://bugzilla.mozilla.org/show_bug.cgi?id=117436#c30 (which was shot down because of a flaw in the test case). In this case even Ctrl-Reload is fast. After restarting Mozilla it is slow again.

Athlon 750, Win2k SP3 Mozilla 1.2 trunk 20020909 - 6800 ms IE6 SP1 - 1502 ms -- After changing Color Deph (from 32 bit to 16 bit) - 3352 ms After switching Color Deph back - 1786 ms I'm very afraid to change it one more...

Please report the color switch problems in bug 157072

ouch - at the testcase at http://www.world-direct.com/mozilla/dhtml/timeouttest.htm got 4 times worse than it used to be!! - see for milestone results overview.

My check in for bug 164931 probably affected this. see the follow comments http://bugzilla.mozilla.org/show_bug.cgi?id=164931#c12 http://bugzilla.mozilla.org/show_bug.cgi?id=164931#c24 The maximum frame is now 100fps now that we use timers instead of posted WM_APP events for plevent notification.

Well, if you look at the testcase at http://www.world-direct.com/mozilla/dhtml/timeouttest.htm the current build is far away from 100 fps - more like 1 fps.

using 2002092008 trunk build on WinXP 750Mhz machine. Actual time :: Time between setTimeout and function: 100 :: 90 190 :: 90 290 :: 100 390 :: 100 530 :: 140 681 :: 151 821 :: 140 941 :: 120 1051 :: 110 1161 :: 110 1261 :: 100 1361 :: 100 1452 :: 91 1562 :: 110 ...

wow - something strang's going on here: trunk build 2002091908 on win-xp pro,1.1ghz,512ram (see complete testresults in attachment). 1021 :: 1021 2043 :: 1022 3064 :: 1011 4095 :: 1021 5117 :: 1022 6138 :: 1021 7160 :: 1022 8181 :: 1021 9203 :: 1012 10234 :: 1021 11256 :: 1022 12277 :: 1021 ... so that's about 10 times slower!

Tested now all available nightlies on ftp (puhh!) and 0.9.7 till 1.2a --> it seems that my last GeForece2 Go driver update makes this now that slow, as the slowdown happens on all recent builds now. Also affecting the testcase at http://www.world-direct.com/mozilla/dhtml/75121/anim-test.htm Just 0.9.8 behaved as it was before the video driver update. Did we change something considerably in view of scaling/painting after 0.9.8 ? What is still as fast as msie is the testcase at http://www.world-direct.com/mozilla/tt/timeouttest_resized.htm (the ball.gif is already resized to mozilla doesn't have to do it) which delivers 110 as average. I will do further investigations with all builds on several other workstations.

firstly, my system is: Athlon 1.2 GHz, 3dfx Voodoo 3 2000, Win98 SE ok, testcase results: http://www.world-direct.com/mozilla/dhtml/75121/anim-test.htm mozilla 2002092008: 5650 netscape 7 RTM: 2580 http://www.world-direct.com/mozilla/dhtml/timeouttest.htm mozilla 2002092008: between 170 and 220 netscape 7 RTM: between 50 and 110

Biesi, does changing color depth make any difference (a la comment #6) for you?

ere: it does. anim-test (haven't tried the other one) now takes twice as long. (I switched 16bit->32bit)

Well, that's something else then. For me it works much better on my work machine if I change the color depth (from 16bit to 32 or vice versa). On my home machine, there is no difference. There are too many moving things here..

DHTML performance regression also noticed in bug 140789.

For comparison: Animtest: Konqueror 3.0.3,Linux 2.4,Nvidia GF, K6-3 500MHz, 192 MB sdram: 2050ms Mozilla 1.0, 19.10.02, Linux 2.4,Nvidia GF, K6-3 500MHz, 192 MB sdram: 4000ms (looks a bit strange)

Trunk 20020921 761 :: 741 1492 :: 721 2323 :: 821 3274 :: 941 4206 :: 922 5057 :: 841 5838 :: 771 6839 :: 991 7981 :: 1132 8672 :: 671 9333 :: 651 9994 :: 651 10655 :: 651 11496 :: 831 12417 :: 891 13158 :: 721 13960 :: 791 14811 :: 841 15542 :: 721 16724 :: 1172 17655 :: 921 18516 :: 851 19247 :: 721 20259 :: 1002 ...

Forgot to add system spec: Win2k Athlon 750 . And it is regression.

I'm seeing around 2000ms for the testcase on both 1.1 and a current cvs build on Linux. As bug 164931 is a win32 only patch, it really seems suspect to have caused this for win32 people.

->kmcclusk, based on Markus's email telling me that the regression is from bug 164931. Is this more of a problem on certain Windows OSes than others?

Hmmm. This bug was originally reported using a 2002091208 build which pre-dates the 9/18 checkin for bug 164931? Can anyone experiencing a slowdown please try pulling a 9/16 WIN32 build and compare the 9/16 times against a 9/20 or later WIN32 build?

From Markus's comment: http://bugzilla.mozilla.org/show_bug.cgi?id=169748#c15 it sounds like the performance regression is sensitive to the graphics card and driver, which indicates it is probably related to rendering of images. I don't think the performance regression is caused by or made worse by the checkin for bug 164931.

Since according to the comment 15 http://www.world-direct.com/mozilla/tt/timeouttest_resized.htm does not have the performance regression and Moz 098 works fine for images that need to scaled. I would guess the performance regression was introduced back when imagelib was changed to scale images when rendered instead of pre-scaling them?. saari, pav, dcone: Does this sound right?

Just did testing on two worksations having ATI graphics cards on winnt. There is no difference between 9/16 and 9/20 builds. But I made some further investigation and got a nice finding - could achieve a performance boost by factor 10(!) on my GeForce2 Go graphics card. Just see bug 170272.

-> Don.

Color depth.. info for everyone. We create DDB's for a given screen. This means that image is optimized for the card at the depth that the image is created for, and if you switch depths.. after the creation of this image.. it could slow the blit time down as much as 100 times.. depending on the graphics card. This is just a -Beware- note.

Then why we're not reciving any problems with slowing down after deph change? In the same time we're reciving many info about quite nice improvements. Is that logic?

Bulk moving P1-P5 un-milestoned bugs to future.

Marking fixed - fixing bug 170272 did a nice job :) Further investigation about the color switch phenomenon will go on in bug 157072.