Closed Bug 170272 Opened 23 years ago Closed 22 years ago

[DHTML] default windows video hardware acceleration slows us down.

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect, P2)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.3alpha

People

(Reporter: markushuebner, Assigned: dcone)

References

(
URL
)

Details

(Keywords: perf, topembed+, topperf, Whiteboard: Fixed by checkin between Sep22 and Sep23.)

Attachments

(1 file)

test result using www.world-direct/.../timeouttest.html
5.07 KB, text/html
Details
NVIDIA is the leading manufacturer of graphics cards. Just did some investigation on my computer with trunk build 2002092008 (DELL Latitude 810C, win-xp pro,1.1ghz,512ram, video-card: GeForce2 Go @ 32bit color depth, latest driver provided by DELL - driver information provided by win-xp says: Driver Provider: NVIDIA Driver Data: 28.06.2002 Driver Version: 2.9.6.3 Digital Signer: Microsoft ... when running the testcase at http://www.world-direct.com/mozilla/dhtml/timeouttest.htm I get average results of 1012ms Now I went to the "Hardware acceleration" of the video card and went just one step down - it says there: "Disable cursor and bitmap accelerations. Use this setting to correct problems with mouse pointer, or to correct problems with corrupt images". I left the "Enable write combining" ticked. Running the test again yielded great results - the average is now 110ms (10x performance boost!!!) Also trying for example http://www.world-direct.com/mozilla/dhtml/fish2.htm is now so much faster with this setting. I do hope this provides some usefull information of where we can start to track down our (painting) performance problem(s).
Keywords: perf
Blocks: 21762
Summary: Major performance problems with NVIDIA graphics cards → [DHTML] Major performance problems with NVIDIA graphics cards
I also have a NVIDIA graphic card using NVIDIAS drivers 28.32 and I dont have this options. Maybe only DELL drivers have them? And what happends if you try out the latest NVIDIA drivers (30.82)? http://www.nvidia.com/view.asp?IO=winxp-2k_30.82
This option is a Windows OS option - not video driver specific! Just right-click on the desktop - choose properties - settings - advanced - there is a 'troubleshoot' tab and therein you have the hardware accelerator switch.
Markus, does it matter where you leave your cursor when you run the test? That is, is there a big difference if you leave the cursor in the Mozilla window, versus if you move it completely out of the way? What you describe sounds like the general problem that WinXP has with its soft-shadow cursor, which can slow down graphics for a lot of functions. Another way to test is to turn off the cursor shadow and make sure you're not using a software cursor. If turning off the software cursor or cursor shadow fixes this problem, then it's not Mozilla.
On a side note, Mozila seems to have some issues with this option, disabling this option also fixes some graphic corruption with bug 101907. Eventually, S3 fixed their driver which really fixed bug 115452 (the workaround was also to disable this very hardware acceleration).
btw: with this option the testcase at http://www.world-direct.com/mozilla/dhtml/75121/anim-test.htm delivers 1552ms - instead of 7541ms (when having full accelaration). So the problem is not just about scaling performance - this is a general (painting) performance problem.
This is not just Nvidia. I got about 5x perf boost by changing that setting on win2K with Ati Rage 128.
Did turn of shadow of mouse pointer in win-xp, but had no effect.
using an IBM Thinkpad T22 laptop, PIII 900MHz + S3 Savage/IX driver 7.40.54, Win2k SP2, 32-bit. URL: http://www.world-direct.com/mozilla/dhtml/timeouttest.htm with full acceleration: ~800ms cursor acceleration disabled: ~80ms
Summary: [DHTML] Major performance problems with NVIDIA graphics cards → [DHTML] Major performance problems with some graphics cards
The OS dialog actually says "cursor & bitmap acceleration", and I do think it's more a bitmap problem here. Anyway, maybe the Imagelib people have an idea what could cause this.
Reproduced steps from Comment 1. Same results. 1) Without change - 800 ms 2) After one step down - 100 ms 3) Switch back to "full acceleration" - 800 ms
RIVA TNT2 Model 64 32 MB ram BIOS version 2.05.1703 Detonator 40.41 (beta)
Do you see the same kind of performance effects when using Internet Explorer?
No effect on MSIE & Opera.
I think that this testcase wont show any progression in IE. It's because without changing acceleration, we have 100 ms which is ideal speed, and cannot be better. After changing it's still 100 ms.
Do the pages affected by this have anything in common? Or does it affect all pages?
Running testcases at http://guisset.tripod.com/mozilla/testcase/timer.html http://www.world-direct.com/mozilla/dhtml/3dcube/index.htm also showed the extreme performance boost. So it seems overal (painting) performance is affected. Just http://www.world-direct.com/mozilla/dhtml/index.html seems to be (a bit) slower. Gandalf - what about your testcases?
Just tried this on my home machine, winXP SP1, 1,4GHz amd, 1GB Ram, Geforce3: Before changing: An average of 109, all values are in the range 108-111. After changing: Still an average of about 109, but values range from 94 to 125. Same average for IE (109), no change in the range of values before/after.
This may be related. A few days ago, we found a scrolling testcase which is very slow on a particular machine, but was fast on most other machines. If we run IE on the testcase it scrolls quickly. If you leave IE up, Mozilla will now scroll the testcase quickly. If you shut IE down. Mozilla scrolling gets very slow again. I wonder if IE might be changing the hardware acceleration settings which gave Mozilla a performance boost. As a test, Markus could you try the following: 1. Launch IE and run http://www.world-direct.com/mozilla/dhtml/timeouttest.htm. 2. Leave IE up. 3. Launch Mozilla and run timeouttest.htm. 4. Does Mozilla speed up? 5. Exit IE. 6. Run Mozilla on timeouttest.htm. 7. Does Mozilla slow down again?
If IE6 is playing with settings, you could try running it under WINE (possibly Crossover's WINE if stock WINE doesn't work) using -debugmsg relay to get a trace of its API calls.
Following steps fromk Comment 18 - no, i dont see any speed up. Only after "Acceleration" change.
<tor> one thing to try - replace the image on the timeouttest with a similar sized jpeg <tor> that would tell you if it's the alpha mask causing problems <tor> (btw, is that the fixed version of the test that doesn't attempt to rescale the image on each draw?) <matic> thx for the point <matic> that is the testcase where mozilla has to do the scaling <tor> try not scaling as well - make a matrix of the performance <matic> when no scaling is needed the testcase works great also when having full acceleration! (see http://www.world-direct.com/mozilla/tt/timeouttest_resized.htm )
Hmm.. I know there's some sort of long complicated story with two different tiling algorithms and us using one or the other depending on something (dcone worked on this for a while). Do we have a way to force using one or the other exclusively? If so, could we try doing that and testing the effect?
Here's a summary of tweaking the settings mentioned so far in this bugfile for the tests. I've added a 4th one. ------------- 1) Start/Settings/Control Panel/Display/Settings tab/Advanced button/TroubleShoot tab/Hardware acceleration fieldset/ Hardware acceleration None P Full | | | | | | You should be able to read "Disable cursor and bitmap accelerations. Use this setting to correct problems with mouse pointer, or to correct problems with corrupt images" "Enable write combining" checkbox checked. 2) Start/Settings/Control Panel/System/Hardware tab/Device Manager fieldset/Device Manager/ Display adapters/Right click on NVidia .../Choose properties/Driver tab Driver Provider: NVIDIA Driver Data: 7/16/2002 Driver Version: 3.0.8.2 Digital Signer: Microsoft Windows Hardware Compatibility Publisher 3)Start/Settings/Control Panel/Mouse/Pointers tab/Enable Pointer shadow checkbox unchecked 4)Start/Settings/Control Panel/Mouse/Pointer Options tab/Visibility fieldset/Display pointer trails checkbox unchecked ----------- I added the pointer trails item because this is a cosmetic display feature which demands/might demand noticeable/non-negligeable cpu and RAM resources.
reassigning -> dcone Cc: pavlov This seems to be closer to the work he was doing with Win32 gfx drivers, tiling, etc. I don't think there is any tiling going on (though there are overlaps), but it appears that something we're doing (scaling? transparency? combining them?) is killing us at full optimization. matic: your comments aren't totally clear as to what happens in what case, especially with regards to scaling.
Assignee: pavlov → dcone
Also affects Win2K, but not Win9x, from what I can tell.
I have no problems on win2k with a GeForce3 or a GeForce4 Ti 4600
Possibly also related to the graphics hardware. The newer cards (GeForce 3 and 4) seem okay, but older cards (GeForce 2, TNT2, SuperSavage, a Trio3D) have this problem. That would imply it's one of the newer ROP2 or ROP3 functions that are now accelerated in Win2K and WinXP, I think.
It is possible that our use of SRCANDing and then SRCPAINTing for drawing images with 1bit masks is causing some problems I guess. I don't know if there is another way to do it that would make things better or not.
Nomanating as this is hurting (DHTML) performance so much (factor 10).
Blocks: advocacybugs, 164421
Keywords: nsbeta1, topembed
Three new testcases: 1) http://www.world-direct.com/mozilla/dhtml/timeouttest_jpg_withscaling.htm with full "hardware acceleration" 5990ms on average(!) [and when the test is finished and I switch to another application and back via the taskmanager to Mozilla it's frozen for a few seconds] with "hardware acceleration" on step down 110ms on average 2) http://www.world-direct.com/mozilla/dhtml/timeouttest_jpg_withoutscaling.htm with full "hardware acceleration" 110ms on average with "hardware acceleration" on step down 110ms on average 3) http://www.world-direct.com/mozilla/columniosity/index_fullscreen.html? fullscreen with full "hardware acceleration" smooth scrolling with "hardware acceleration" on step down quite choppy --- Simple animations like test #3 or the tests at http://www.world-direct.com/mozilla/dhtml/funo/domTestcase2/index.htm (with text and image animation) are quite fast with both "hardware acceleration settings" - thought they are faster when having full "hardware acceleration. So it seems that the performance break-down is going along with the scaling (timeouttest) and distortion (fish2) of images.
Correcting my info from comment #5 - http://www.world- direct.com/mozilla/dhtml/75121/anim-test.htm is also doing scaling.
I have a NVIDIA card and I also see this. Though when viewing the DHTML example: resource:///res/samples/test13.html with "hardware acceleration" on step down it is slower
Ouch! Last testcase: word 'aaa' IE ~ 3000 ms Mozilla ~ 9000 ms
The fish2 demo is just doing scaling and clipping, so it's almost certainly just the scaling that's the problem. And there's no transparency here. So we need to experiment with the Win32 scaling code to find a way to draw the scaled images that avoids the "accelerated" paths these drivers are using.
Blocks: 163975
Pavlov, this is just a wild guess, but is the scaling code using StretchBlt, and do you call SetStretchBltMode before that? I've seen some problems in the past with my own stuff with StretchBlt using HALFTONE mode on NT/2K.
Build 2002083108 Win2k on Dual Celeron 466, 512Mb ram, Matrox G400 Here are my results: Test from bug report: ~328 in full mode ~165 in (full-1) mode Test 1 from #30: ~1062 in full mode ~110 in (full-1) mode Test 2 from #30: ~110 in full mode ~110 in (full-1) mode Test 3 from #30: Smooth in full mode Choppier in (full-1) mode
I'm using an nVidia GeForce 2 card with the 40.52 (Beta 2) drivers on WinXP SP1, and don't see any problems anywhere. And yes, I have Hardware Acc on Full.
It doesn't mean that every GeForce2 is affected by this. But thanks for testing anyway.
One Question: Test 1 on Comment #30, does the image look the same in both accelleration modes, or does full the accelleration one look crisper (more detailed) than the "down one notch" accelleration?
testing with trunk build 2002100308 on win-xp pro the images look the same in both acceleration modes ... also tested http://www.world- direct.com/mozilla/dhtml/fish2.htm
Warner: there is one use of SetStretchBltMode(HALFTONE) in the source. I'm not sure what it affects, though, after just a quick look. http://lxr.mozilla.org/seamonkey/search?string=SetStretchBltMode
I am currently trying to put together data on this bug and talk with the graphics card companies. If you have data on a particular graphics card.. please name the make, model and driver used.. then the problem. I am putting together a matrix to track these cards. Another interesting issue I found.. I found a computer that the graphics runs very very slow (background tiles makes scrolling painful on the espn NFL site). But if I start explorer, and go to that same page.. Mozilla magically gets very very fast on that page. If I then quit Explorer.. Mozilla will slow down again. Looking into that issue also. Something you may want to try... see if explorer can make your graphics card faster. But you have to be on that page to see the speed increase.
OK, to expand on my Comment #37. I'm using a nVidia GeForce2 MX/400 with the Detonator 40.52 (Beta 2) drivers as supplied by nVidia. (i.e. not from www.guru3d.com or some other site that has links to "leaked" drivers). I had no problems with any of the tests, and I wasn't running IE at the same time.
Additional graphics card stats: Although I am running an older version of Mozilla (1.1 release) on my Windows 2000 machine (AMD-K7 850Mhz), I see similar results running test 1 from comment #30 above. My graphics card is an ASUS V6800, which is an NVidia GeForce256-DDR based card. I am running the Nvidia Detonator drivers, Version 28.32. I am running at 1280x1024x32bits. Accelerated, the times were about 420. Unaccelerated, the times were about 100.
I repeated the same tests with the latest driver from Matrox and a more recent Mozilla. Now guess what happened... Old config: Build 2002083108 Win2k on Dual Celeron 466, 512Mb ram, Matrox G400 driver v5.72.021 New config: Build 2002082704 Win2k on Dual Celeron 466, 512Mb ram, Matrox G400 driver 5.86.32 Here are my results: Old config New config Test from bug report: full mode ~328 ~110 (full-1) mode ~165 ~110 Test 1 from #30: full mode ~1062 ~110 (full-1) mode ~110 ~110 Test 2 from #30: full mode ~110 ~110 (full-1) mode ~110 ~110 Test 3 from #30: full mode Smooth Smooth (full-1) mode Choppier Choppier Apparently someone at Matrox pushed the magic button.
GeForce2 MX/ Athlon 750/ Win2k Nvidia drivers 4.0.7.1 Because my results with newest trunk were amazingly good ('Standard column') i decided to try push it to maximum, and see results. i dont think that "someone in Matrox...". I think that somewhere here, in Mozilla, something was pushed. But while testing with "1ms Timeout", i still see that "full-1" mode is faster! (if You want to reproduce my results, remember that Mozilla sets option in select. So if you're reloading page after changing mode set 'Timeout' select to anything annd switch back to 1ms)
Here are my results: Standard 1 ms Timeout 1ms Timeout+30 Balls Test from bug report: full mode ~100 ~40 ~160* (full-1) mode ~100 ~10 ~40 Test 1 from #30: full mode ~100 ~300* ~852* (full-1) mode ~100 ~10 ~20 Test 2 from #30: full mode ~100 ~20 ~20 (full-1) mode ~100 ~10 ~10
Test 3 from #30: full mode Smooth n/a n/a (full-1) mode Choppier n/a n/a * - whole browser almost freeze It was strange. I had feeling that, in thos 3 points, whole browser alomst feezed even before displaying page. I even restarted computer and cleared cache, after fisrt time i saw it.
I'm not sure about those results. Whole machine worked quite fast until Test 1 '1 ms Timeout'. After this, every time i changed mode to full-1 all worked OK, but when i switched back to full mode, browser freezed. I made those 3 test few time more to be sure. Everytime same result - freezing. Restart of browser, deleteing cache, restarting browser, nothing helped. (sorry for chopping posts, but i have problem with bug 135182, and every long post on this bugzilla (my private works OK) resylts in 'document contains no data')
My work have this problem with their S/W, too. We never fixed it (we just ship our systems with the slider turned down), but IIRC I traced it to doing a BitBlt() between 2 memory DC's. I always figured that the driver was trying to accelerate the BitBlt(), but this was hurting performance because neither the source or destination was the screen buffer and it was having to do extra copies across the bus. I hope this helps track it down. God knows how you fix it, though.
ah, that suggests you may want to try running some tests with double-buffering off (pref "viewmanager.do_doublebuffering" to "false").
Most of our image draws are copying between memory DCs because we draw everything into an offscreen buffer and then copy the result to the screen. If the problem is with BitBlt, then we could consider changing nsImageWin to detect when the destination DC is a memory DC and doing the blit by hand.
No longer blocks: 1.2b
jjmata sees this on winxp, Netscape 7.0. the default OS config is full hardware accelleration, so, we're obviously severely degrading performance on most systems. I'm putting bumping this to topperf.
Keywords: topembed → topembed+, topperf
changing summary from "[DHTML] Major performance problems with some graphics cards". I'm not seeing a connection between specific video cards given all the comments in this bug.
Summary: [DHTML] Major performance problems with some graphics cards → [DHTML] default windows video hardware acceleration slows us down.
Jud: this affects cards which use Nvidia chips and particular versions of the nvdida drivers.
It's not only nVidia. I've seen it on one system with ATI card, I think. (don't remember the model now). I believe I also saw this with Matrox G100 on one system, but I'm not sure about that.
kevin, see comment #8, it also affects S3 Savage cards, i.e. every new and not-so-new IBM laptop.
Ok, just to clarify. It is not affecting all cards. And the cards that are affected depend on the driver being used. According to comment #45 Matrox G400 driver v5.72.021 (slow) Matrox G400 driver 5.86.32 (works fine) ATI 3D RAGE IIC AGP works fine. Out of 20 machines with various graphics cards in our local office. None of them exhibit this problem. Can someone who is seeing this problem, try setting the pref "viewmanager.do_doublebuffering" to "false")as Robert suggests in comment #51? We are working on getting a configuration in-house that fails so we can debug the problem.
Further Clarification. From reading this bug. The cards that are affected only slow down when needing to scale the image during a bitblt. If the DHTML testcase's are modified to *not* scale the bitmaps as they are moved, performance is fine with full acceleration on the affected cards.
Also affected see comment #11 - and some older graphics cards. Hope that a testing environment is soon available to be able to track this down.
Trying out Robert's sugestion in comment #51 seems to have no major positive effect. What should the desired effect look like exactly?
Okay, this keeps getting weirder and weirder. I was wrong in #45 on my assumption that someone at Matrox pushed the right button. Braniecki was right in #46 that someone at Mozilla pushed the right button. That means that I can reproduce my results on build 2002083108 and not on 2002092704 or later, all regardless of the driver version. I have no setups from in between that period. Furthermore I noticed that the speed differs per colordepth: Build2002083108 on Win2k, Dual Cel 466, Matrox G400, driver v5.72, 1024x768, fully accelerated: Test 1 from #30 8 bit ~250 16 bit ~590 24 bit ~870 32 bit ~1060 That I can understand, but then I decided to change the colordepth during the test. I saw that before the change the speed was like above but after the change the speed was much higher. The speed after changing colordepth: Test 1 from #30 32->24 ~110 32->16 ~125 16->32 ~170
*** Bug 157406 has been marked as a duplicate of this bug. ***
URL from dupe - http://www.colinriley.com/ and Rene - seems you are mentioning the x-files bug :) bug 157072
ok, now I am puzzled too. Following up on my results from comment #44 In order to try and rule out driver revisions and Mozilla revisions, I did the following: 1) Upgraded my Nvidia (GeForce256) drivers from 28.32 to 30.82. Re-ran the test 1 in comment #30 using Mozilla 1.1 release. Like I reported before, Unaccelerated (-1) was faster than full accelerated (about 400 to 100). 2) Upgraded my Mozilla to 1.2Beta, and re-ran the test 1 in comment #30 and now it times at about 110 (between 100-120) for both accelerated and un-accelerated! So something changed in the Mozilla code that seems to have made a difference for me (and yes, I reconfirmed by uninstalling Mozilla and re-installing the older version again).
OK I just ran this through VTune at work. Sampling (system wide) shows that 60% of the time the test was running, the CPU was inside memmove() in ntoskrnl.dll. It also spent some time (2%ish) in EngStretchBlt() in Win32k.sys. A full call graph (of the process) showed that the vast majority of time (26.5 out of 30 sec) was spent in nsRenderingContextImpl::DrawScaledImage(). VTune did not show the call to img->Draw(), so I assume it didn't find symbols. I can only assume that's where the time is really going. Note that I have an installed build, so the only symbols I have are those supplied (presumably for the talkback feature). I also don't have source code here, let alone the ability/time to build (they might notice I should be working). FYI, My card is an NVidia TNT2 Model 64. It exhibits the problem with Mozilla 1.1 when the acceleration is turned all the way up but not with it notched down a step (timeouttest.htm w/ default params times at 500-600ms vs 90-125ms). I'm running Windows 2K w/ latest NVidia drivers (v 6.13.10.4041) I can also confirm that Phoenix 0.3 (which I believe is based on nightlies. i.e. post 1.2alpha) does not exhibit the slowdown here. I don't know whether that is because of a change in nsIImage::Draw() or nsRenderingContextImpl::DrawScaledImage(). Possibly the fix for bug 87819 helped in this case?
From Microsoft's DDK, EngStretchBlt: This function allows the same halftoning algorithm to be applied to GDI bitmaps and device surfaces. The driver should call EngStretchBlt if it has hooked DrvStretchBlt and is called to do something the driver does not support. So, from the sounds of it, the video card driver gets a StretchBlt (DrvStretchBlt) call, determines that it can't handle it properly, and sends it back for the OS to handle (EngStretchBlt) See also Bug 153367. One cause could be our palettes usage is screwed up. This could also go back to "the mess that was Bug 135226", which initially changed: // Version 3.147 ::SetStretchBltMode(aNewDC, COLORONCOLOR); in SetupDC(), to: // Version 3.148 ::SetStretchBltMode(aNewDC, HALFTONE); This caused CPU usage to double, and was later "backed out" (technically not backed out, rather repatched to be in sync with the 1.0 branch which had a mystery checkin) by another patch, which changed the above SetStretchBltMode line to: //Version 3.150 // Temporary fix for bug 135226 until we do better decode-time // dithering and paletized storage of images. nsPaletteInfo palInfo; mContext->GetPaletteInfo(palInfo); if (palInfo.isPaletteDevice) ::SetStretchBltMode(aNewDC, HALFTONE); else ::SetStretchBltMode(aNewDC, COLORONCOLOR); This made the CPU usage go back to normal for me, because the COLORONCOLOR was restored. Perhaps the video cards in question are being set to HALFTONE? Just ony of many possibilities.
So, can anyone reproduce the bug in nightlies? Or is it gone for everyone? Someone who used to be able to reproduce the bug but can't anymore should try to narrow down the change window by downloading nightlies from different dates and trying them out. Thanks!
I downloaded 1.2Alpha (2002091014) and was able to reproduce the original problem. So the change occurred between Mozilla 1.2Alpha (2002-09-10) and Mozilla 1.2Beta (2002-10-16). I can try it on different nightlies, but there doesnt seem to be nightlies (trunk) that are earlier than 10-16-2002 (which is basically the date for 1.2Beta). Are these older nightlies archived somewhere other than ftp://ftp.mozilla.org/pub/mozilla/nightly ?
You can sometimes find older nightlies in some of the mirror sites. Some of the ones you are looking for are here: ftp://ftp.uninett.no/pub/network/www/mozilla/mozilla/nightly
I don't have access to all the nightlies in that time frame, but I do have some. Testing with those lets me narrow down the change somewhat. Build 2002-09-20 is still slow, but build 2002-09-25 is fast on the exact same machine, so at least we know the code change happened after Sep 20 and before Sep 25.
Priority: -- → P2
Target Milestone: --- → mozilla1.3alpha
I narrowed it down a little more. 2002-09-24-08 build does not have a problem, either, so the change that seemed to fix this is between Sep 20 and Sep 24.
Lets see if we can narrow it down even more. I did a pull with: mk_add_options MOZ_CO_DATE="22 Sep 2002 08:00:00" compiled (Windows), and zipped up the dist/bin dir to: http://animecity.nu/mozilla/2002092208.zip
Arron, I downloaded your Sep 22 build, and it still exhibits the slowness, so that narrows it down to a checkin between Sep22 and Sep24.
Not much was landed on the 22nd, so I did a build MOZ_CO_DATE="23 Sep 2002 13:00:00" http://animecity.nu/mozilla/2002092313.zip
Arron, I downloaded http://animecity.nu/mozilla/2002092313.zip and it works fine :) So we know it happened between Sep22 and Sep23.
Following up... that would make the corresponding bonsai query: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=09%2F22%2F2002+08%3A00%3A00&maxdate=09%2F23%2F2002+13%3A00%3A00&cvsroot=%2Fcvsroot Looking at this output...Could it be a checkin for bug 169483 in which prefs (and perhaps default behaviour) were added to enable/disable double-buffering?
Actually, I just found out I'm one hour out (timezones, gotta hate them). Here it is with the right times: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&sortby=Date&date=explicit&mindate=2002%2F09%2F22+07%3A00&maxdate=2002%2F09%2F23+12%3A00&cvsroot=%2Fcvsroot Markus, could you verify that you had : pref("viewmanager.do_doublebuffering", true); or no entry for do_doublebuffering, when you ran the second one? The first zip forces doublebuffering, while the 2nd one relies on a pref.
Arron, when using http://animecity.nu/mozilla/2002092313.zip I had pref("viewmanager.do_doublebuffering", true); in all.js and everything was smooth.
Whiteboard: Fixed by checkin between Sep22 and Sep23.
Looking at the checkins referenced in Comment #79. I suspect the backing out of the patch in bug 104934 which turned off the MOZ_UNICODE flag because it caused a number of regressions is what fixed this perf problem.
Resolving as fixed. I added a note to bug 104934 indicating that the patch in bug 104934 is the suspected cause of this bug. All of the known regressions which were initially caused by turning on the MOZ_UNICODE flag has been fixed, so I think the MOZ_UNICODE flag will be turned on again soon. When bug 104934 is resolved as fixed anyone who was experiencing the slowdown reported in this bug should try running the tests again.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Confirming. Checked few tests from this bug (comment #1,comment #5) and this bug is fixed for me (Mozilla 20021105)
Zbigniew: Here is the test result I run with Unicode and without Unicode. Can you give me a feedback on the result? How do you read the results?
Roy, as mentioned try changing timeout to 10 ms and balls to 50. This will give us much cleaner probe.
This bug is not fixed. It's still alive on URL from bug 194627.
Blocks: 194627
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
If it's fixed on some but not all URLs, then there are multiple bugs involved. Please file appropriately. (Hint: the component this bug is in is _not_ the component you should be filing on.)
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Right. Sorry for this. About component - it's not my bug.
No longer blocks: 164421
No longer blocks: 21762
Blocks: 21762
Blocks: 158464
Product: Core → Core Graveyard
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: