Closed Bug 96633 Opened 23 years ago Closed 22 years ago

slow display of background image (100% CPU)

Categories

(Core :: Layout, defect, P3)

x86
Windows 2000
defect

Tracking

()

VERIFIED FIXED
Future

People

(Reporter: markushuebner, Assigned: pavlov)

References

()

Details

(4 keywords, Whiteboard: [adt3])

Attachments

(1 file)

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.
Summary: Extrem slow display of background image → Extreme slow display of background image
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.
Assignee: karnaze → 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.
Summary: Extreme slow display of background image → slow display of background image
i'm working on a few things for this.. taking bug
Assignee: dcone → pavlov
Target Milestone: --- → mozilla0.9.5
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.
Keywords: mozilla0.9.5
.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Blocks: 71668
Keywords: mozilla0.9.6
CPU usage 100% at http://www.trust.at
There is an animated background gif bringing mozilla down.
Target Milestone: mozilla0.9.6 → mozilla0.9.8
*** 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
Keywords: nsCatFood
Keywords: mozilla0.9.7
Summary: slow display of background image → slow display of background image (100% CPU)
Keywords: mozilla1.0
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).

Keywords: nsbeta1
Target Milestone: mozilla0.9.8 → mozilla0.9.9
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;
    }
Keywords: helpwanted
A profile of http://corp.pixel-industries.com would be very much appreciated 
to further analyse any relating issues.

Keywords: mozilla0.9.9
Keywords: nsbeta1+
Status: NEW → ASSIGNED
Priority: -- → P3
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.
Keywords: nsbeta1
Target Milestone: mozilla0.9.9 → mozilla1.0
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?
Keywords: mozilla1.0+
Keywords: mozilla1.0
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.
Keywords: mozilla1.0+mozilla1.0-
Whiteboard: [adt3]
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.
Keywords: nsbeta1-
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.
Keywords: nsbeta1+
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"
Target Milestone: mozilla1.0 → Future
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!
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
--> verified
Status: RESOLVED → 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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: