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)
Tracking
(Not tracked)
M14
People
(Reporter: sdagley, Assigned: pnunn)
References
Details
(Whiteboard: [Perf])
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
Reporter | ||
Comment 2•26 years ago
|
||
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.
Comment 3•26 years ago
|
||
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.
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.
Updated•26 years ago
|
Summary: [PP] First load of an image is very slow → [PP] First load of images is very slow
Comment 6•26 years ago
|
||
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.
Comment 8•26 years ago
|
||
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.
Comment 10•26 years ago
|
||
Setting all current Open/Normal to M4.
Updated•26 years ago
|
QA Contact: 1698
Comment 11•26 years ago
|
||
[QA Assigning to Self]
Comment 12•26 years ago
|
||
Putting on [Perf] radar also.
Updated•26 years ago
|
Target Milestone: M4 → M5
Comment 13•26 years ago
|
||
pnunn's not here for the m4 endgame. moving to m5
Assignee | ||
Comment 14•26 years ago
|
||
Steve:
Is this still true?
-pn
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
Comment 15•26 years ago
|
||
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!
Reporter | ||
Comment 16•26 years ago
|
||
I didn't observe the bug myself, I just logged it during the [PP] push for the
Mac.
Comment 17•26 years ago
|
||
Duh. Sorry. Will ping Pierre.
Updated•26 years ago
|
Status: RESOLVED → REOPENED
Target Milestone: M5 → M6
Comment 18•26 years ago
|
||
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.
Updated•26 years ago
|
Resolution: WORKSFORME → ---
Assignee | ||
Comment 19•26 years ago
|
||
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
Comment 20•26 years ago
|
||
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
Assignee | ||
Comment 21•26 years ago
|
||
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
Comment 22•26 years ago
|
||
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?
Assignee | ||
Comment 23•26 years ago
|
||
This does happen on windows.
-pn
Comment 24•26 years ago
|
||
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.
Assignee | ||
Comment 25•26 years ago
|
||
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.
Comment 26•26 years ago
|
||
And on Linux too.
See: http://bugzilla.mozilla.org/show_bug.cgi?id=8061
Setting to All platforms.
Comment 27•26 years ago
|
||
*** Bug 8061 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 28•26 years ago
|
||
Assignee | ||
Comment 29•26 years ago
|
||
I need necko to land to address this properly.'
-pn
Target Milestone: M8 → M10
Comment 30•26 years ago
|
||
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).
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → DUPLICATE
Comment 31•25 years ago
|
||
*** This bug has been marked as a duplicate of 18738 ***
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 32•25 years ago
|
||
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!
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•