W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

fast rendering of text, containing images (Was: Persistent ...)

From: Balint Nagy Endre <bne@bne.ind.eunet.hu>
Date: Tue, 12 Sep 1995 22:31:09 +0200 (MET DST)
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http WG <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <32.bne@bne.ind.eunet.hu>
Jeffrey Mogul writes:
> Of course, Netscape users have come to expect early rendering of
> text layout because Netscape can discover the shape of the first
> four (or so) images before fully retrieving any of them.  I agree
> that this is a valuable property to preserve.  Several months ago,
> we had a somewhat noisy debate about other techniques for early
> delivery of image size and shape without having to use Netscape's
> parallel-connection model.
Netscape has an additional trick in rendering text, containing inlined images:
uses the WIDTH=x and the HEIGHT=y attributes in the IMG tag.
(This will be a HTML/3 feature, I guess.)
(If the image has different size, netscape scales it accordingly.)
> I believe we never came to a conclusion at that time.  If I recall
> my own preferences (I could have this wrong), I strongly favored
> inventing a new HTTP method that would return the "shape" of an
> image without returning the whole thing.  So, a typical retrieval
> of a page with four images might look like:
> 	GET page.html
> 	<one RTT delay>
> 	GETSHAPE image1.gif
> 	GETSHAPE image2.jpeg
> 	GETSHAPE image3.gif
> 	GETSHAPE image4.gif
> 	GET image1.gif
> 	GET image2.jpeg
> 	GET image3.gif
> 	GET image4.gif
Hmm, use of IMG attributes is cheaper, than implementing a new method
and making an extra request per inlined image. (Not requires support in
servers, but in html authoring tools support is desired.)
> Note that, unlike the Netscape model, which breaks down if you
> need more than 4 images to decide how to render the text, this
> mechanism scales to arbitrary numbers of images.  It doesn't
> allow the browser to render several images simultaneously, but
> I think that is a much less useful feature if the alternative
> is faster completion for all images!
Under Linux, I use normally 16 connections! Four is the default!
> Someone will no doubt flame me for suggesting that the server
> has to understand the shape of images.  Go ahead, flame away;
> I'm leaving for a two-week trip in 30 minutes, so I won't be
> around to defend myself.  But I'll point out that we could
> make server support for GETSHAPE optional, without affecting
> correctness (and in thise case a greedy browser could always
> revert to a parallel-connection approach).
Great idea, but Netscape has a better one.

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>
Received on Tuesday, 12 September 1995 13:46:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC