Closed Bug 13375 Opened 21 years ago Closed 21 years ago

[Perf] small gif in background makes page VERY slow


(Core :: ImageLib, defect, P1)






(Reporter: pierre, Assigned: dcone)





(2 files)

Verified with recent builds on Mac and Win32:
- Open Messenger
- Wait until the default page is displayed in the message pane
- Resize the window
==> It's slow

Alternatively, you can open this default message in Navigator:
I will also attach an HTML snippet.

The problem comes from the background which is drawn using a very small gif (2x2
pixels) at this URL:

The problem is also MUCH more visible if you disable offscreen drawing (ie. if
you define NO_DOUBLE_BUFFER in nsViewManager.cpp)
Attached file HTML snippet
CCing <ducarroz> who first noticed the problem and <phil> who may be interested
because it affects Messenger quite a bit.
Assignee: pnunn → dcone

I think dcone is working on this.
The 4.x code had a nice algorithm from
kevina, that built up blocks based on
patterns of 8.

Reassigning to dcone.
Keep me posted.
Pam  -- Can we request from the image library a block of images, like an 8x8
image for a background?  That way when we know we have a small background we can
build up a tile right away and use that.
I'm not sure that makes sense. The imglib doesn't know anything
about where an img is used and this only makes sense for small
images used in backgrounds... and the 'block' size may be
platform specific.

It makes sense that the block would be made in somesort of
background cache. I'll go peek at that code in the FE.
*** Bug 6145 has been marked as a duplicate of this bug. ***
*** Bug 14547 has been marked as a duplicate of this bug. ***
Eli - you may want to save this URL off somewhere.  I'm working with the
Netcenter folks to change to use BGCOLOR instead of the gifs.
Attached image gif image
Thanks. Between the 1-pixel GIF and the HTML attached earlier by Pierre, I think
there's enough to easily reproduce.
add myself to cc: list.
Severity: normal → blocker
Priority: P3 → P1
Marking this as a BLOCKER.

Here's another URL that demonstrates the problem:

In running Quantify to determine why resizing of the page is so slow, I found
that we spend 16.31 percent of our time in StretchBlt rendering the background,
which on this page is a 2 pixel high image
Closed: 21 years ago
Resolution: --- → FIXED
Fixed, small background images now build larger tiles (using a Binary
duplication).. then this larger image can be used to blast in the background...
Using Pierre's test this, this looks fine on 19991090908 Win32 and 1999101108.

It didn't look fine on the 10.8.99 Mac OS build; thus, I'm going to hold from re-
opening or verifying this bug until we have a newer build, in case the fix wasn't
picked up in that build.
Doh. The second date was obviously for Linux.
Verified fixed using 1999 10/12 08:00 Mac OS build (also using Pierre's test
You need to log in before you can comment on or make changes to this bug.