User:Brahmana/Netwerk Docs/Image Loading

Images defy a lot of rules that the previous docs mention. The most of them being sharing channels. If there are multiple requests raised for a single image, and by single image I mean image file referenced with the same URI, then there is only one netwerk connection that is spawn for each of those requests(which are essentially channels) and all the channels are fed from the same underlying netwerk transaction. Note that this is different from caching. In case of normal requests the caching will work only when there is a request for a document, which was already requested earlier and the earlier transaction is over and the data is in the cache. But in case of images, even when multiple requests are simultaneous all requests are sort of bundled together and fed from the same netwerk transaction.

Note: By netwerk transaction I am not referring to the nsHttpTransaction class. Its used as a generic term. From what I know, mostly its the nsHttpConnection object that is shared amongst the requests. << This needs validation (Biesi/bz) ? >> [There may not be anything shared between the requests. They don't always reuse connections. --Biesi 15:53, 4 August 2008 (UTC)]

Another major difference is that rarely do any of the image load requests go through docShell. The requests arising from <img> tags, which are probably the highest, do not use docShell. docShell will come into picture only when an URI pointing to an image is loaded by entering directly in the URL bar.

So as of now I assume the request is created by the DOM parser when it starts parsing the base HTML page and finds <img> tags. [It's not really the parser that starts the requests, it's the DOM node (nsHTMLImageElement via nsImageLoadingContent) --Biesi 15:53, 4 August 2008 (UTC)] Since there is sharing of netwerk layer resources between multiple requests for the same image, the parser might as well wait, bundle all the <img> tags pointing to the same URI and then place requests for each bundle, instead of creating a new request for every <img> tag it encounters. << This needs validation (Biesi/bz) ? >> [I don't really understand what you are saying here. The bundling is currently done by the imgLoader. Are you suggesting that this is done at a different level? Why? Also keep in mind that it may be multiple tabs/pages sharing the image load --Biesi 15:53, 4 August 2008 (UTC)] [@Biesi : You answered my question. I had not considered the case of the multiple tabs/pages accessing the same image. So with only one page in mind, I thought the parser would put together all <img> with same src's and create a single request for them. But now as you said this discretion of either reusing an existing channel or creating a new channel is done by the imgLoader and not the parser]

Note: Here, by request I am referring to an nsIRequest object, which I think is a nsIChannel in most cases.(Though at some point later the old request is replaced with an imgIRequest type).

The control flow for an image load is shown in the diagram. <<coming soon>>

Abstract Notes from chat and code browsing

• There is a content sink for every document that is parsed.(nsHTMLContentSink for HTML docs). It is this content sink that creates the corresponding objects for every tag element in the doc. (Eg: an nsHTMLImageElement for an <img> tag).
  • Just FMI, This content sink is part of the parser.
• This is what bz said about content sink in a conversation with me:

<bz>	contentsink basically takes a stream of callbacks from the parser and constructs a DOM tree
<brahmana>	thats it?
<bz>	more or less, yes
<bz>	there's some hackery in there to do with headers because of <meta> tags
<bz>	but other than that....

• From the channel the data will eventually be fed into some image decoder for image requests.