Closed Bug 12155 Opened 26 years ago Closed 4 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: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.