Just go to the URL http://www.payplus.at/aboutpayplus.asp and see the display speed of the background image. This started to happen about one week ago. Using build 2001082303

adding keywords

Hrmm.. it seems to load fine for me on win2k, build 20010822. I do, however have a high-speed connection (150k/sec), and it loads in an instant (the whole page took 1.532 seconds to load). However, the image is only about 16k, so if it is a problem, it's probably not related to file size. Also, to be sure.. you mean the greyish background image, right? Could you explain a little better on what happens, and what you expected to happen?

Adding self to CC.. Also, not major, but the summary has a spelling error: "Extrem" should be "Extremely" or "Extreme" I am not empowered to make the change

I am having the same line-speed (150kb/s) and using a PentiumIII 500MHZ, 256RAM. The problem is not the loading time ... the top graphic is being displayed and then there is the white background (bgcolor) and then line by line (would say about 100 pixels) is horicontally being displayed. This rendering should be way faster! In build about one week ago I didn't mention the building of the background image at all.

I'm afraid I still can't reproduce the problem. I won't add any more comments here (unless someone else notes WFM), because I don't seem to have the problem. I had first thought, maybe it was the computer processor and memory.. but now that you mention your computer specs, I realize this probably isn't the case. I have a pentium 333mhz processor (compared to your 500mhz), and I have only 130mb RAM (compared to your 256mb). [do you have enough free processing power and memory not being used by other programs or processes?] I downloaded the same build as you report from (2001082303), and still no difference. I then force refreshed the page (shift-reload), and no difference (I was thinking maybe it was a cache problem). Then, I cleared both my memory and disk cache, but still no difference :( Have you tried either of those? Also to comment on: The "br_payplus.gif" image next to the title bar loads after the background loads (or displays). When the page loads, it takes under 2 seconds to completely load and render (display) the page. Have you noticed such a problem on any other websites? If so, you could list those as well.

Does removing the "script" tags in the head cure anything? The rest of your code looks perfect. Maybe it is related to that javascript... (just a thought)

I see this slow load behavior on 2001082109 Win2k with a fast network connection. It seems that the entire page loads, and then the background is rendered a second or so later. Not sure why. It appears that there's some code at the end of the ext.js function that is loaded if (innerWidth!=document.MM_pgW || innerHeight!=document.MM_pgH) that seems to force the page to reload immediately. Perhaps that's the cause?

Reassigning to dcone.

using build 2001082909 the problem is still there. you really can see the "building of the background image". don't really know what caused this slowing down and exactly since when. hope someone can help.

i'm working on a few things for this.. taking bug

I have a large Jpeg that displays extremely fast(just flashes onto the screen) when it is not being used as a background image. When I use it as a background it displays slowly like a window shade being pulled down. It takes 1.3 sec when it is not a background image and 4+ secs as background image. I am using a 333Mhz with 128mb and OS/2. I just wanted to point out that it is its use as a background image that seems to be causing the slow down.

I have already talked about this bug with pavlov, he knows how to fix - he has taken it.

Isn't bug 64188 just a particular case of this one?

just noted that when including a real huge background image (300kb) the speed is incredible slow ... you can follow the display centimeter by centimeter.

.

CPU usage 100% at http://www.trust.at There is an animated background gif bringing mozilla down.

*** Bug 108167 has been marked as a duplicate of this bug. ***

Major performance problems on the URL reported in the DUPE http://www.devx.com/free/hotlinks/2001/pointcounter102401/pointcounter_CPvsRJ.as p

This one is also causing 100% CPU usage but I am not sure if this is related to this bug http://corp.pixel-industries.com/index2.html

original URL perf win is fine now thanks to checkin to bug 98252, build 2002-01-10-03.. mac perf is still an issue, so stay tuned to #98252. #19, that one is both animated images and some background images.

Another test url: http://java.isavvix.com/index.jsp In this one both scrolling and entering username/password in the edit fields are very slow (on build 20011221106).

I have a hack that helps with large background images. It waits to the entire image is loaded before displaying it. It speeded up on my tests 2 -3 times. In addition, it is way less annoying than the slow slice by slice painting. The patch is in the nsCSSRendering::PaintBackground routine in nsCSSRendering.cpp. if (NS_FAILED(rv) || !req || !(status & imgIRequest::STATUS_SIZE_AVAILABLE) || !(status & imgIRequest::STATUS_LOAD_COMPLETE)) { //perf hack if (!transparentBG) { // The background color is rendered over the 'border' 'padding' and // 'content' areas aRenderingContext.SetColor(aColor.mBackgroundColor); aRenderingContext.FillRect(aBorderArea); } return; }

A profile of http://corp.pixel-industries.com would be very much appreciated to further analyse any relating issues.

http://corp.pixel-industries.com is bug 124999. Also, once the patch for 125025 (maybe) and bug 125137 are applied this may be worth rechecking.

Removing nsbeta1 nomination because this bug has been plussed.

the original URL appears to be fixed, probably bug 122996 fixed it. build 2002-2-21-03 w2k.

Not seeing any performance problem (K6-III/400, 192MB ram, Win 98, build 2002022308.). Because I'm on slow 64kbps connection, I downloaded it locally for further testing. Background image is loaded adequately fast. Cpu usage is normal, animating effects at speed similar to IE. Time to resolve it as fixed/wfm?

Here is a simple testcase with a non-animated .gif background. http://members.optushome.com.au/clef/mozilla/pa/

with the fix for 85771, this problem seems to be fine. We now wait until background images are fully downloaded before displaying them.

On http://www.penny-arcade.com I still get several seconds of 100% CPU usage on any repainting (waiting for the page to load fully then minimize and restore window). Telling Mozilla to use my colors/backgrounds causes rendering to happen instantly. However, http://members.optushome.com.au/clef/mozilla/pa/ given in comment 29 which is a page with just the same background image works fine. Related but different bug? Win2k build 2002031708

This page shows this problem as well: http://www.geocities.com/rabidbandit/index2 win2k build 2002031803

The penny-arcade site now displays smoothly for me (was a problem only recently) and my testcase above with just the background for penny-arcade now also goes perfectly smooth. However some other test cases in this bug still go very very slowly so I'm guessing they were different problems.

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.

after looking at this, the test case http://www.geocities.com/rabidbandit/index2 uses MORE CPU in IE (95%) than it does in Mozilla (60%). Doing full screen animated backgrouns *is* going to be slow. Don't do it! http://www.penny-arcade.com seems to be a win32 image tiling bug. check dcone's bug list for dups. This should either be marked "WORKSFORME" or "WONTFIX"

I see this on http://www.unwrap3d.com/index.html using Mozilla build 2002042608 under WinXP. Near 100% cpu usage and extremly slow scrolling , test selection ..etc

CeeJay: What video card and driver (version)? Acceleration settings? Does changing the acceleration settings make it better?

I did some further investigation and found that http://www.icehardware.net/ was an execellent testcase for the problem I was seeing because it had two really big gif as backgrounds .. one for the page and one for the main table. Blocking thoose images cleared the problem right up .. and the page also rendered fast before the images loaded. I however found a much better solution - I switched to a newer build. The lastest for today couldn't start mail and news so I tried 2002042906 and it works perfectly on this page and all the other pages ... except the ones with animating backgrounds where the problem is as huge as it ever was. http://www.geocities.com/rabidbandit/index2 f.x is very slow. My video card is a noname TNT2 M64 - 32MB RAM The windows acceleration settings is at max I haven't tried altering the settings yet.

I was visiting this page : http://toastytech.com/evil/index.html , which also renders really slow because of an animating background .. but the background here isn't that big and still it renders very slow. I thought i might have something to do with how heavily the memmory on the videocard was taxed but I might have been mistaken. Correct me if I'm wrong but doesn't the new build store the images directly in the video memmory ?

Just to note, I have been experiencing the same problems with the 'problem' webpages listed in this but, BUT, in today's build (2002050204) on WindowsXP, the problem has vanished. Maximum CPU processor usage is now around 35% (very acceptable) Has there been a 'fix' (maybe from a related bug)? No hardware/display settings were changed. Does the problem vanish for anyone else?

it could be bug 102321 - will do further testing and provide infos here then.

Ryan, thanks for the note. I just grabbed the latest Windows build and you are correct, the painting issues related to transparent backgrounds that have existed since v0.9.8 appear to have been addressed. Or, at least, all of the issues that I had been experiencing are happily gone. Thanks to whomever did the fix!

A fix was checked into the trunk yesterday for bug 135226, which also fixed bug 102321, which fixed a whole load of slow scrolling/rendering regressions.

Yeah - this one got fixed. using 2002050208 :)) Nice work dcone & saari!

--> verified

using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0+) Gecko/20020507 I find that the problem seem to have gone on : http://toastytech.com/evil/index.html but it still remains on: http://www.geocities.com/rabidbandit/index2 Something improved but the problem is not quite gone yet.

What does.. not quite gone.. is this site that your talking about.. how fast does it scroll, or what exactly are the symptoms your talking about. We had a few problems with .. what slow or fast is.. can you quantify what problem your having.

The link http://www.geocities.com/rabidbandit/index2 is terrible slow on my PIII, 500 Mhz, 256 MB, Win2000 SP2 with Mozilla build 20020505. CPU Usage goes up to 100%, the mouse is difficult to move around and scrolling is really slow.

Same here. That link is not quite as slow as it was when I first added that link as one that exhibited this bug. But its still not smooth at all and is very shoppy when you scroll. This is on a 1.5ghz athlon w/ 512mb ddr ram and win2k sp2 and mozilla build 2002042608. http://www.geocities.com/rabidbandit/index2

puh - using trunk build 2002050608 on win-xp,1.1ghz,512ram the cpu pegs to 100% and the mouse jumps terrible around. But this conversation should go on in bug 138034 I think.

dcone : to clarify .. http://toastytech.com/evil/index.html Now runs at almost the same spiffy speed as most pages , the speed difference is hard to notice , and doesn't disturb your experience of the page. http://www.geocities.com/rabidbandit/index2 Shows a small improvement in speed from earlier builds , but still runs very slow. With speed of the two pages I mean the speed which they scroll , the responsiveness of the mozilla UI while on that page. UI responsiveness covers navigation the menu's (bookmarks , tools .. etc) , the time between a rightclick and the popup menu apearing and cursorchanges .. etc. http://www.geocities.com/rabidbandit/index2 slows the browser to 1 - 3 fps and CPU usage maxes out at 100% http://toastytech.com/evil/index.html causes the CPU usage to rise to between 60 and 70 % Scroll the page down just enough so you can't see the two animating browser-anti-ads ( "Internet Explorer IS EVIL" and "Nuke Internet Explorer" ) and the cpu usage drops to a third (20 - 23%) .. exactly a third .. which leads me to conclude that there is some connection between the number of animating images on screen and cpu usage since the number of animating image on-screen is also reduced to a third. If you view the background image for http://www.geocities.com/rabidbandit/index2 in it's own window using the function "view background image" the cpu usage is also 20 - 23% When I said there was some improvement I meant that the first page seems to be at almost full speed and the second seems slighty faster than before (it used to have below 1 fps) This bug should probably not be set as verified fixed as more than one person can verify the opposite.

There is also a great difference in CPU usage if you use 16bit or 32bit color depth mode - this is mentioned in bug 117436.