56612 - Display of large images is twice as slow as Nav4x

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Pierre Saslawsky]

Tested with different builds on the Mac and Win98:

- go to http://people.netscape.com/pierre/Bike.jpg (a 44Kb image)
- go to http://people.netscape.com/pierre/Passport.jpg (27Kb)
- click back and forth the Back and Forward buttons
==> the display of each image is almost instantaneous

- go to http://people.netscape.com/pierre/Structures/structures-black.jpg (154Kb)
- go to http://people.netscape.com/pierre/Structures/structures.jpg (88Kb)
- click back and forth the Back and Forward buttons
==> BUG: the display of each image is very slow, you can see them draw by blocks 
(on the Mac at least) and it takes 1.2s for the 88K image and 1.9s for the 154K 
one. Compare with MacNav4 and MacIE5: MacMoz is really much slower.

The problem also occurs when you click back and forth between one these two large 
images and one of the two small ones. In a word, it looks like the loading of any 
image of more than 64K flushes the cache and forces a reload of all the 
subsequent images. That would be bad...

Comment 1

[Fabian Guisset]

Unable to reproduce this bug. All 4 images load instantly on Build 2000101320
Win32 after being viewed once. Check that your cache is enabled. (Not sure how
to do it).
Fabian.

Comment 2

[pnunn]

Pierre: What are your cache prefs? Validate once per session?
-pn

Comment 3

[Pierre Saslawsky]

I have the default cache settings:
 - Memory = 1024
 - Disk   = 7680
 - Compare once per session

You should try it on a 56K line, it is really obvious that the image doesn't come 
from the line but it is still very slow: between 2.8 and 4 seconds for each image 
(a bit slower than in my first comments where I was using DSL, if that makes a 
difference - which it shouldn't if everything was coming from the cache).

I noticed something interesting though: when we go back and forth between a big 
image like
  http://people.netscape.com/pierre/Structures/structures-black.jpg
and a page without a single image like
  http://www.mozilla.org/webtools/bonsai/cvslog.cgi
or even a page with a small image like
  http://people.netscape.com/pierre/Passport.jpg
then the big image displays instantaneously.

There must be something wrong with the cache for images larger than 64K or so.  I 
can see the 88K image displayed in approximately 8 chunks and the 154K image in 
approximately 13 chunks. 

In some cases, it even reloads the image from the network.  The following 
sequence did it for me (reproducible):
 - go to http://people.netscape.com/pierre/Passport.jpg
 - go to http://people.netscape.com/pierre/Structures/structures-black.jpg
 - switch back and forth a little bit, finish in structures-black.jpg
 - go to http://people.netscape.com/pierre/Structures/structures.jpg
 - go back to structures-black.jpg
==> the image is loaded from the network
 - go back to Passport.jpg
==> the image is loaded from the network
 - go forward to structures-black.jpg
 - go forward to structures.jpg
 - go back to structures-black.jpg
==> the image is loaded from the network again

Comment 4

[Pierre Saslawsky]

Needless to say that this bug really hurts the performance during normal web 
surfing, especially on 56K lines like AOL users have.

Changing severity and milestone.

Comment 5

[pnunn]

Assuming the cache changes take care of this problem,
I'm setting the target for .9

Comment 6

[pnunn]

All pnunn bugs reassigned to Pav, who is taking over
the imglib.

Comment 7

[Stuart Parmenter]

is this still the case?

Comment 8

[Terri Preston]

pierre, are these images gone or moved?

Comment 9

[Gagan]

terry: Lets find some big images and test this out before making a call on 
whether this is a nsbeta1 or not. Pierre can you tell us how big these images 
once were? Or just get these up on a test server. Thanks!

Comment 10

[Pierre Saslawsky]

The size of the original images was specified in the comments when I opened the 
bug report.  Sorry, I moved them.  If you want new ones to play with, you can try 
http://people.netscape.com/pierre/NewPics/5-BurningMan/columns-bw.jpg and
http://people.netscape.com/pierre/NewPics/5-BurningMan/windsocks.jpg

Comment 11

[Pierre Saslawsky]

...and I confirm that the problem is still there.

Comment 12

[Terri Preston]

Changing status to [imglib]

Comment 13

[David Hallowell]

Seems fine to me on Win2k, image loading was comparable to IE6

Comment 14

[Pierre Saslawsky]

I originally noticed the problem on MacOS and Win98.  Maybe the problem was fixed 
on Win98...  

Comment 15

[Terri Preston]

I believe this was fixed by the new imglib, images opened quickly on w98 build 
2001042604, mac build 2001042605 and a linux debug build from 4/25/01

Comment 16

[Rob Foster]

I would have to agree with Preston. Image load times from cache are improved in
my build from 4/25/01 vs 4/18/01. The builds from 4/18/01 did display this
problem but it seems to be back to "expected" speeds with 4/25/01

Comment 17

[Pierre Saslawsky]

Reopening and changing the title from "Display of large images is very slow" to 
"Display of large images is twice as slow as Nav4x".

I used today's Mozilla 0.8+ and Nav4.72.  In both applications I did the 
following test:
- load image #1
- load image #2 in the same window
- click 20 times Back and Forward (ie. 10 times each).
==> On a PowerBook 500, Nav takes 16 seconds while Moz takes 33.5 seconds.

Comment 18

[Stuart Parmenter]

this could be related to a few things.. first that we currently paint each
individual row of jpegs, second that the memory cache is set to 1mb, so we're
probably kicking this out immediatly after decoding it.

Changing platform to Mac since it is fast everywhere else.

Comment 19

[Simon Fraser [no longer active]]

We paint individual rows? Euch. Sounds similar to 73969.

Comment 20

[Adam D. Moss]

Are we still talking about the cache settings quoted by Pierre?
e.g.
 - Memory = 1024
 - Disk   = 7680

... because neither image is likely to fit in imglib's
cache (since it stores decoded images, which is fine --
where the image fits), so the images are being pulled from
HTTP-cache and redecoded.  In difference to Nav4.x, that
also implies a reading the data from disk too, since at this
time the NewCache is disk-bound (and MacOS <X would suffer more
because its IO caching isn't as streamlined at the system
level as other platforms).

Correct me if I'm wrong.

I think that would explain a lot of the relative unpleasantness
on Mac with these cache settings, though.

Comment 21

[Adam D. Moss]

Setting dependancy upon 77218, "Disk cache and memory cache
settings are the same as 4.x in 1997"

Comment 22

[Adam D. Moss]

(Which is recently fixed. ;) )

Comment 23

[Terri Preston]

Attachment: testcase 1

Comment 24

[Terri Preston]

Attachment: testcase 2

Comment 25

[Terri Preston]

Tested this with today's mac build 2001050208, loads very quickly!  Closing as 
resolved/fixed

Comment 26

[Terri Preston]

Verified fixed mac build 2001052405