W3C home > Mailing lists > Public > public-respimg@w3.org > November 2014

Re: Informing the browser of the expected size of the image

From: Yoav Weiss <yoav@yoav.ws>
Date: Thu, 6 Nov 2014 20:41:01 +0100
Message-ID: <CACj=BEgNizOARjRZqo2S+NzVbYassxgZ99uQsr7VLxGnDCWN8Q@mail.gmail.com>
To: Frédéric Kayser <f.kayser@free.fr>
Cc: "public-respimg@w3.org" <public-respimg@w3.org>, Simon Miles-Taylor <smilestaylor@gmail.com>, Ilya Grigorik <igrigorik@google.com>
Google's John Mellor experimented with a similar idea a while back.
You can see the gist of it at
http://yoavweiss.github.io/respimg-blinkon-presentation/#/71/2 (click the
down arrow to see the image download progress. Apologies for the huge
images that are downloaded as part of the presentations :/ )

On Thu, Nov 6, 2014 at 8:24 PM, Frédéric Kayser <f.kayser@free.fr> wrote:

> Hello,
> I sought a bit about this before going to bed and wake up with this idea,
> HTTP/2 servers could send progressive JPEG images sliced exactly at scan
> borders (each progressive "refinement pass" is called a scan and starts
> after a xFFDA Start Of Scan marker), the effect could be especially neat if
> servers send the first image scan of each image first, this could be
> relatively fast. To get an idea of the data size needed to send just this
> part you can apply JSK (JPEG Scan Killer
> <http://encode.ru/threads/1800-JSK-JPEG-Scan-Killer-progressive-JPEG-explained-in-slowmo>)
> to a progressive JPEG and check the size of the first file it produces.
> Parsing a JPEG file to find the scan borders is quite easy and fast since
> no real decompression of the image has to be performed, it could be done in
> realtime or cached if needed.
>
> Frédéric Kayser
>
> Le 5 nov. 2014 à 01:48, Ilya Grigorik <igrigorik@google.com> a écrit :
>
> Simon, I'm not sure I follow.. I think what you're describing is
> orthogonal to what Kornel and I are saying.
>
> With HTTP/2 the server can send the first KB (or whatever amount) of the
> image to allow the browser to decode the image header and get the geometry
> of the image much earlier.. which minimizes reflows during initial page
> load (which is awesome).
>
> ig
>
> On Wed, Nov 5, 2014 at 9:01 AM, Simon Miles-Taylor <smilestaylor@gmail.com
> > wrote:
>
>> IIya,
>>
>> The trick with images is to put them in a Div and the text underneath
>> that way the browser can place the text underneath and deposit the image
>> into a "container" above.
>>
>> If you put a Null image preceding the real image with Height of 100% and
>> Width of 0 and use vertical align on both images you will get vertical
>> alignment.
>>
>> I cheat I have VB code that collects and stores the image attributes.
>>
>> Simon
>>
>> On 4 November 2014 22:14, Ilya Grigorik <igrigorik@google.com> wrote:
>>
>>>
>>> On Fri, Oct 31, 2014 at 10:38 AM, Kornel <pornel@pornel.net> wrote:
>>>
>>>> > On 27 Oct 2014, at 17:03, steve@steveclaflin.com wrote:
>>>> >
>>>> > Now, in particular, when we could have images with different aspect
>>>> ratios, it seems like the browser wouldn't know until it downloads one what
>>>> the aspect ratio is.  And we might end up with a very jumpy page.
>>>>
>>>> For this I'm rooting for "smart" HTTP/2 servers that can push all image
>>>> file headers (that contain image dimensions) to the client very early, and
>>>> resume sending of the rest of the image data only after other assets have
>>>> been sent. In theory HTTP/2 allows servers to do this automatically with
>>>> very little overhead and it would "just work" without need for any extra
>>>> markup.
>>>>
>>>> Of course, we're not there yet. I feel your pain, interaction between
>>>> image height and max-width is really annoying.
>>>
>>>
>>> s/we're not there yet/we'll be there in few weeks time/
>>>
>>> Chrome 39 is shipping http/2 in stable, so is FF 35. Meaning, in a few
>>> weeks time we'll have a significant fraction of users running HTTP/2
>>> capable browsers... and we can start experimenting with above server
>>> implementations.
>>>
>>> ig
>>>
>>
>>
>
>
Received on Thursday, 6 November 2014 19:41:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:15 UTC