Steve: I'll need some help building in the new world on the mac. help. P.

Steve: I'm not seeing this problem on the new build. Could it be local to your tree? -pn

I didn't see this myself and was just logging it from reports brought up at the MacDev meeting. I'm adding Pierre to the cc: list as I think he's the one that reported it.

I can still see it with today's build. It's very noticeable, even on a G3. To reproduce: - Quit "viewer.app" if it is running - Launch "viewer.app" - Wait until the test8.html is fully loaded - In the "Sample" menu, select "Sample 2" ==> The image of the Raptor is very slow to load.

I see it. Thanks much. -pn

elig...get a watch with a second hand, get together with Sujay and tell us what is very slow. Load this image on Win NT, Linux and Mac and give us a timing please.

It's not particular to that image. All images are very slow to load the first time. Go to any page with plenty of images or small icons: the total time to load them is way superior to Windows or Mac Communicator.

I'm trying to track when images finish decoding vs. when they display. A delay in the display could exist in imglib or layout or netlib.

See also bugs 2611 (generally slow loading complex pages), 2132 (DNS is synchronous on Mac now), and 2231 (threading issues with netlib need work). Some or all of these may be related to this problem.

Inserting Milestone info.

Setting all current Open/Normal to M4.

[QA Assigning to Self]

Putting on [Perf] radar also.

pnunn's not here for the m4 endgame. moving to m5

Steve: Is this still true? -pn

Steve, I'm not seeing a perceptible delay on my 604e, although it's possible I've merely acclimated to modest performance expectations. ;) Do you still see the performance problems that you originally observed when you wrote this bug up? Thanks!

I didn't observe the bug myself, I just logged it during the [PP] push for the Mac.

Duh. Sorry. Will ping Pierre.

The images load faster than they used too but there is still a problem. If you open test2.html with Communicator, the page is displayed in a single pass. If you open the same file with Viewer or AppRunner, the page displays the text in a first pass then in a second pass, it does a relayout with both the text and the raptor image. So, I agree, the raptor image loads faster than before (maybe because I have a G3 now) but the basic problem seems to be still here. It acts as if the images were so slow to load that the page had to be displayed in 2 passes. Note: - As originally described, the problem only happens the first time the image is loaded. When it's in the cache (ie. if you use Back/Forward or if you open a second window with the same page), it loads in a single pass. - When comparing Communicator and Gecko, don't forget to clear the Communicator cache (or to click Option-Reload on the Mac). Reopening with Target set to M6 instead of M5.

I'm sorry. I need something more quantifiable than seems slow. Demo 2 on viewer on linux, displays the same way you describe as being too slow on the mac. There is no way that displaying an image is going to as fast as displaying text. Can we get some numbers on this? -pn

A quantifiable way to describe the problem is: Number of passes to load test2.html with Communicator = 1 Number of passes to load test2.html with Gecko = 2

Aren't we talking apples and oranges here? The new layout engine handles pages and images differently than it did in 4.x. Why use the number of passes used? -pn

Because it's possibly related to how fast the images are loaded. The first time the page is displayed, there is a first pass to display the text only, then a second pass where the text is reflowed and the image is progressively displayed. The image is displayed faster than it used to back in January when the bug was first opened but it still appears fairly slow for a local image file when compared with another application like JPEGView. The second time the image is displayed (ie. when the image is already in the cache), the layout is done in a single pass and it doesn't seem to present any performance problem. Maybe I'm wrong in my explanation of the problem, which is "loading an image is so slow that it causes Layout to display the page in two passes instead of one"... Do you know why it doesn't happen on Windows?

This does happen on windows. -pn

Ooops, ok... It's the way it works on Windows too. Try http://pierre/Test/TheAnimatedPage.html : this one works fine on Windows while it is quite slow then fails on the Mac.

I know of 2 things I can try to speed things up on the mac. One, use ramiro's quick fix for rgb/bgr ordering for the mac as well as X. I'd like to fix this the Correct Way, but I'll need more FE help. Two, I can hack the image request for looping image to see how much netlib is a contributor to the mac slowdown. After that, we'll see.

And on Linux too. See: http://bugzilla.mozilla.org/show_bug.cgi?id=8061 Setting to All platforms.

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

This may or may not be duplicated by bug#8061. I am unduping Bug#8061 and putting the platform back to Mac for this bug. The bugs are probably related, but may not be the same bug. Keeping them separate is less confusing. -pn

I need necko to land to address this properly.' -pn

On MacOS 8.5.1 using the latest NECKO build 1999080312, i don't see any problems with the images loading. However, the animated .gifs seem to flicker a lot now (they didn't do this with the pre-NECKO builds).

*** This bug has been marked as a duplicate of 18738 ***

As far as I can tell, sfraser's extensive analysis on 11/17/99 in bug #18738 subsumes this bug. Thus, rubber-stamping as Verified/Duplicate. Pierre, please re-open if there's more to it that I've missed. Thanks!