Closed Bug 12155 Opened 25 years ago Closed 3 years ago

should load non-displayed images less aggressively

Categories

(Core :: DOM: Core & HTML, defect, P5)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: dbaron, Unassigned)

References

(
URL
)

Details

(Keywords: dom0, perf) 

I filed this after working on bug 11518.

DESCRIPTION:  Images created (in script in the HEAD) with "new Image()" and then
img.src = "..." are being loaded *before* the images actually displayed
initially in the document.  This makes loading *really* slow on this page.  I'm
not sure whether 4.x loaded both at the same time or the displayed ones first,
but it's much faster.  I think you need to load all images that are actually
being displayed before you pre-load the others.  (When one of the preloaded ones
is triggered, though, it should be loaded sooner.)

STEPS TO REPRODUCE:  Load above URL
(http://www.saturn.com/models/l_series/wagons/lw2/lw2_exterior.html )

ACTUAL RESULTS:  I watch little gray boxes for eons, but no images come in for
quite a while (over a modem).

EXPECTED RESULTS:  The document loads reasonably fast (for it's size).

BUILDS TESTED:
 * Linux, apprunner, 1999-08-16-08-M9.

DOES NOT OCCUR ON:
 * Linux, Communicator 4.6.
Does this happen on Win or Mac?
OS: Linux → All
Hardware: PC → All
ALSO DOES NOT WORK CORRECTLY ON:
 * Windows, apprunner, 1999-08-24-09-M10

Marking All/All.
Moving all non-DOM[012], non-crash bugs to M15.
Scott, since netlib didn't really have a weighting mechanism, do you know what
we did for 4.x?
In 4.x (and earlier versions) we adjusted the priority of loading an image by
changing the size of the netlib buffer used to transfer data to the imagelib.
All other things being equal, a larger buffer request should result in a faster
data request rate to the netlib and hence a faster transmit rate because the TCP
stack on the server will enlarge the transmission window.

That's not the whole story, however.  The order in which images are
requested will also affect the relative speed at which they load because the
netlib limits the number of simultaneous socket connections.  (I can't remember
what the limit is.  Say, for the sake of argument, that the limit is four
simultaneous connections.)  If, say, a page commences loading of ten
"low-priority" images followed by some "high-priority" images,  none of the
high-priority images will even *start* loading until seven of the low-priority
images complete loading.  I can't really think of a simple way to work around
that problem in the Navigator.  Naturally, the content could be modified to use
scripted image objects so as to load the most important images first.
Netlib could be modified to attach a priority to each read request.  The queue
of channels waiting for a socket transport could then be sorted in priority
order...
One more thing, now that I think of it: In 4.x, we adjusted the priority of
images based on whether or not they were currently visible on the screen.  I
recall that it made a substantial subjective improvement in page loading.
In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.
Keywords: perf
Bulk add of "perf" to new keyword field.  This will replace the [PERF] we were
using in the Status Summary field.
Keywords: 4xp
Setting the keyword all open [4.xp] bugs to 4xp.
Summary: [4.xP] should load non-displayed images less aggressively → should load non-displayed images less aggressively
Whiteboard: [Perf]
Moving to M17
Target Milestone: M15 → M17
This bug has been marked "future" because the original netscape engineer
working on this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work
in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M17 → Future
I disagree with the decision to mark this future. It might sometimes be a huge 
performance win to actually load the elements earlier that are initially visible 
on the screen. Adding mozilla1.0 keyword
Keywords: mozilla1.0
Sorry for the spam, just adding to CC list.
Keywords: dom0
any progress on this bug?
Yes, I remember reading about how NS4 loaded images based on whether they were
visible or not. If you had the images on the part of the page currently in the
viewport, they would load first. Then the other parts of the page, then the
javascript ones. I remember making a page around this because it was a large
thumbnail gallery with mouseovers. I had to load the mouseover images in the
page before in a tiny frame so they'd get in the cache.

If this bug still has the same magnitude as it did before all the rewrites (6
months ago) It really should be reconsidered for, say, moz1.1
this page doesn't exist anymore.
This might show some page-load improvements, and more than that would almost
certainly show improved UI (perceived performace), since users mostly are
concerned when the visible portion of the page finishes loading, not images to
be used for rollovers or images at the bottom of the page.
Shuttling this over to Pav to see if he has any interest in fixing this. While
not technically an libpr0n issue, implementation will require his involvement.
Assignee: vidur → pavlov
Status: ASSIGNED → NEW
Does Mozilla currently track if an image is visible or not?  Could it try to
load images with sizes above 1x1 before images below that (or with no size)?
So... now that image loading lives in content, where do we want to go with this
bug?  Content tends to not have a concept of "visible", but it does have a
concept of "not in the document".... So for nodes that are not in the document
we could defer loading, I guess....
Assignee: pavlov → nobody
QA Contact: desale → general
Bulk priority change, per :mdaly
Priority: P3 → P5

There's a lot of challenges with this due to the "global" load event; fortunately we have <img loading=lazy> these days.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.