13375 - [Perf] small gif in background makes page VERY slow

Status: VERIFIED FIXED

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

Description

[Pierre Saslawsky]

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)

Comment 1

[Pierre Saslawsky]

Attachment: HTML snippet

Comment 2

[Pierre Saslawsky]

CCing <ducarroz> who first noticed the problem and <phil> who may be interested
because it affects Messenger quite a bit.

Comment 3

[pnunn]

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

Comment 4

[dcone (gone)]

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.

Comment 5

[pnunn]

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

Comment 6

[Simon Fraser [no longer active]]

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

Comment 7

[Phil Peterson]

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

Comment 8

[lchiang]

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.

Comment 9

[Eli Goldberg]

Attachment: gif image

Comment 10

[Eli Goldberg]

Thanks. Between the 1-pixel GIF and the HTML attached earlier by Pierre, I think
there's enough to easily reproduce.

Comment 11

[lchiang]

add myself to cc: list.

Comment 12

[troy]

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

Comment 13

[dcone (gone)]

Fixed, small background images now build larger tiles (using a Binary
duplication).. then this larger image can be used to blast in the background...

Comment 14

[Eli Goldberg]

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.

Comment 15

[Eli Goldberg]

Doh. The second date was obviously for Linux.

Comment 16

[Eli Goldberg]

Verified fixed using 1999 10/12 08:00 Mac OS build (also using Pierre's test
case).