- From: Yoav Weiss <yoav@yoav.ws>
- Date: Thu, 6 Nov 2014 20:41:01 +0100
- 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>
- Message-ID: <CACj=BEgNizOARjRZqo2S+NzVbYassxgZ99uQsr7VLxGnDCWN8Q@mail.gmail.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