[Perf] small gif in background makes page VERY slow

VERIFIED FIXED

Status

()

Core
ImageLib
P1
blocker
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: Pierre Saslawsky, Assigned: dcone (gone))

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
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)
(Reporter)

Comment 1

19 years ago
Created attachment 1608 [details]
HTML snippet
(Reporter)

Comment 2

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

Updated

19 years ago
Assignee: pnunn → dcone

Comment 3

19 years ago
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
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 4

19 years ago
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

19 years ago
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

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

Comment 7

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

Comment 8

18 years ago
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

18 years ago
Created attachment 1839 [details]
gif image

Comment 10

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

Comment 11

18 years ago
add myself to cc: list.

Updated

18 years ago
Severity: normal → blocker
Priority: P3 → P1

Comment 12

18 years ago
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
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 13

18 years ago
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

18 years ago
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

18 years ago
Doh. The second date was obviously for Linux.

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 16

18 years ago
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.