Closed Bug 13375 Opened 25 years ago Closed 25 years ago

[Perf] small gif in background makes page VERY slow

Categories

(Core :: Graphics: ImageLib, defect, P1)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: pierre, Assigned: dcone)

References

()

Details

Attachments

(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: http://messenger.netscape.com/bookmark/4_5/messengerstart.html 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: http://home.netscape.com/messenger/start/images/ltgreen.gif 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 (deleted) —
CCing <ducarroz> who first noticed the problem and <phil> who may be interested because it affects Messenger quite a bit.
Assignee: pnunn → dcone
Pierre: 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. -pn
Status: NEW → ASSIGNED
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. -pn
*** 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 (deleted) —
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: http://dvdresource.com/dvdfaq/dvdfaq.shtml 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
Status: ASSIGNED → RESOLVED
Closed: 25 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.
Status: RESOLVED → VERIFIED
Verified fixed using 1999 10/12 08:00 Mac OS build (also using Pierre's test case).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: