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)
CCing <ducarroz> who first noticed the problem and <phil> who may be interested because it affects Messenger quite a bit.
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
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.
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.
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
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 case).