This is split off from bug 117436 comment #30. On recent tests the numbers where cut in half! (trunk build 2002071108 on win- xp).

This phenomenon is seen when either increasing or decreasing color depth. It seems that changing color depth is causing some things to speed up considerably ... let's investigate :)

Some graphics cards are very dependent on depth. The speed increase/decrease can be alot depending on color or video memory.

I see numbers cut in half on the testcase using a GeForce2 Go with 32MB and a Riva TNT2 with 32MB

Does NS4 and IE also show faster DHTML if you change the color depth?

Re: Additional Comment #2 From dcone@netscape.com 2002-07-12 06:49 ------- > Some graphics cards are very dependent on depth. The speed increase/decrease > can be alot depending on color or video memory. That would cause lower bit depths to be faster, and higher bit depths to be slower. comment 1 says that the test also runs faster when *in*creasing color depth. I've tested this ( <http://www.formula-one.nu/mozilla/timeouttest.htm> ) myself and cannot confirm it. 7901 @ 32bit, 6429 @ 16bit (of course it works faster; less colors need to be calculated, and the video ram can be used for other stuff) and then 7952 back at 32bit. Tests run on an Athlon/500 with a 32 Megs ATi Rage 128 card.

I'm getting similar results as Comment 5. I'll need a testcase before I can look into this one. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020719

Does the performance increase persist when you change video modes up/down and *then back again*?

I've seen this too. This has really nothing to do with the graphics card or driver performance. It doesn't make any difference if the resolution or color depth is increased or decreased and if it's changed back to the original settings. Performance boost will persist as long Mozilla is running even, but it will be slow again if Mozilla is restarted (just Mozilla, not the os). This does not seem to happen on all systems though. Please read comment 30 in bug 117436 (http://bugzilla.mozilla.org/show_bug.cgi?id=117436#c30), there is more about the testing.

Confused, by i have to confirm this one. On My Windows 2000 with Riva TNT2, Athlon 750. I'm using 1152x864 and 32 bit deph. Changed to 16 bit - performance progrssion! Changed back to 32 bit - still performance progression(!!!!!) Closed all Mozilla windows and started browser again - regression to "normal". I'm totally confused about this.

hmm, i can't confirm this (winXP, p3500, 128mb ram, voodoo3500tv) but this test gives me almost random results anyway, even if i reload the page every time and do it a few times. but i love this bug! spooky. i'm giving it the alias x-files.

And you dont see that this balls move faster after Deph change????

It does not happen on all systems.

http://www.formula-one.nu/mozilla/timeouttest.htm is a bad testcase because it runs faster the second time around even if you don't change bit depth (at least on my system) So if you are using the testcase, make sure you press shift-reload each time you run the test. Also, include your video card in your results (perhaps this is video card specific).

Humm.. so it is. I can't reproduce the performance gain if I Shift-reload the page after changing display settings. The funny thing is I don't see the second-time improvement without changing the settings (even if I just reload the page without Shift).

There is a new test case in bug 169748. It shows the speed-up even when Ctrl-reloaded.

Changing testcase as long I can put this to another server.

Here are some things I found. On some cards.. the fewer colors the faster the blitting. I made a small test application using 32, 24 and 8 bit images and blitted to the screen many times. It seemes most graphic cards were alot faster on 8 bit displays and the slowest on 32 bit displays.. regardless of the size of the image being blitted to the screen. I think this bug just backs that up. Another not.. not all cards did this.. but 80 percent of the ones I tested did. I think its graphics card dependent.

That makes sense as a general rule because of the different system->video memory bandwidth requirements of lower bit depths. That's not what's curious and spooky about this bug though, c.f. comment #1 "This phenomenon is seen when either increasing or decreasing color depth."

The problem is that I see it on *increasing*. Read Comment #8 as well. Tested (once more) on Mozilla 20021115

just dropped in and found this interesting bug. I tested 20021129 in win2k workstation, with NVIDIA Vanta/Vanta LT display card. The results for anim-test.htm: 1) 16 bit color depth, randomly mix reload and shift-reload. all reload show slightly above 4500 ms, all shift-reload give slightly below 4500 ms. 2) IE 6 SP1 gives 1562 ms, no matter reload or shift-reload. The timing is amazing stable (got 1563 ms once or twice). 3) change color depth to 32 bit, without reloading mozilla. Ignore the first try (which is slow, 7031 ms), try out reload and shift-reload many times, mixed randomly. Got uniformed results: reload: slightly above 5300 ms shift-reload: slightly above 5200 ms (I know it's counter-intuitive that shift-reload can be faster than reload). During all my test I leave cursor on the reload button after clicking, so it won't inter- fere with the painting in the client area. 4) restart IE 6 SP1 and it still give 1562 ms, no matter reload or shift-reload. It seems ignorant of the color change. 5) I'm sending this and then I'll restart mozilla. Then I'll log in to report the data.

OK I'm back. 5) restarting mozilla and test in 32-bit color mode. result exactly same as reported in 3). Mozilla is aware of color change, but ignorant of restart. 6) switch color back to 16-bit while moz watching. Ignore the first reload (3750 ms, surprisingly), the repeated testes give same result as reported in 1). 7) IE 6 SP1 stubornly gives 1562/1563 ms, restarted or not, reload with shift- or not.

I can't reproduce, defaulting this bug back to module owner

for build 20021216 I still observe what descripted in comment #20 and #21. New test case: keep mozilla running and switch from 16-bit color to 32-bit color and then back to 16-bit color, now mozilla is almost as fast as IE. Then keep mozilla and switch from 16-bit to 8-bit color, mozilla slows down.

Hm, who is capable of investigating this?

Maybe bug 153367 is somehow related?

Hmm... i changed whole machine since my last comment here. Now i'm under WinXP, Athlon 1.8, 512 DDR, GeForce 4 MX 440... and... my results are different. At now: 1) Starting mozilla with one window. Color deph is 32 bit - average time: 1600 ms 2) Changing color deph to 16 bit - average time: 3600 ms !!!! 3) switching back to 32 bit - average time: 1600 ms

The testcase has much improved with me with the 3-6-2005 build. In 2005-03-04 build: 4029ms In 2005-03-06 build: 1923ms Using Duron 600MHz, WinXp, NVidia GeForce MX 100/200, 16 bit color depth. Changing the color depth without restarting makes the testcase very slow for me, though (appr. 6000mx), quite the contrary as what this bug is stating.

I'm getting an average of 1500ms , no matter what the color depth is. Is this bug still valid ?

This was probably fixed by the landing of bug 326273

Markus, can this bug be closed?

I will try to test again with various video card vendors to verify this.