Closed Bug 2151 Opened 26 years ago Closed 25 years ago

[PP] First load of images is very slow

Categories

(Core Graveyard :: GFX, defect, P3)

Product:
Core Graveyard
Component:
GFX
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 18738

People

(Reporter: sdagley, Assigned: pnunn)

References

Details

(Whiteboard: [Perf])

Status: NEW → ASSIGNED
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.
Summary: [PP] First load of an image is very slow → [PP] First load of images is very slow
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 Contact: 1698
[QA Assigning to Self]
Whiteboard: [Perf]
Putting on [Perf] radar also.
Target Milestone: M4 → M5
pnunn's not here for the m4 endgame. moving to m5
Steve:
Is this still true?
-pn
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Target Milestone: M5 → M6
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.
Resolution: WORKSFORME → ---
Priority: P1 → P3
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.
Target Milestone: M6 → M8
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.
Status: REOPENED → ASSIGNED
Hardware: Macintosh → All
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. ***
Hardware: All → Macintosh
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
Blocks: 8691
I need necko to land to address this properly.'
-pn
Target Milestone: M8 → M10
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).
Target Milestone: M10 → M14
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 18738 ***
Status: RESOLVED → VERIFIED
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!
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.