95
edits
User:Brahmana/Netwerk Docs/Image Loading: Difference between revisions
User:Brahmana/Netwerk Docs/Image Loading (view source)
Revision as of 14:05, 8 August 2008
, 8 August 2008added abstract notes part and 1 reply to biesi's note
No edit summary |
(added abstract notes part and 1 reply to biesi's note) |
||
| Line 5: | Line 5: | ||
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. | 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) --[[User:Biesi|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 --[[User:Biesi|Biesi]] 15:53, 4 August 2008 (UTC)] | 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) --[[User:Biesi|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 --[[User:Biesi|Biesi]] 15:53, 4 August 2008 (UTC)] | |||
[@[[User:Biesi|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 [http://mxr.mozilla.org/mozilla-central/source/modules/libpr0n/src/imgLoader.cpp#256 some point later] the old request is replaced with an imgIRequest type). | Note: Here, by request I am referring to an nsIRequest object, which I think is a nsIChannel in most cases.(Though at [http://mxr.mozilla.org/mozilla-central/source/modules/libpr0n/src/imgLoader.cpp#256 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>> | 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. | |||