Reading through the comments I'm clearly in the minority, but:
For many of these I like the SVG as much as the full image, and start to wonder if the preview/placeholder makes having the actual image irrelevant.
Using SVG as image placeholders
101–110 of 139 posts
Re: Using SVG as image placeholders
#102How have people come to the conclusion that displaying a low-information version of the image to be loaded as a placeholder results in a quicker perceived load? To me all these effects just look rubbish and distracting, with no benefit at all – certainly not the perception of speed. It's not like I can ever understand what the image really is before it's fully loaded anyway, with our without fancy placeholder.
Then use it only for images below the fold?
Loading images as soon as they are within viewport is already too late. You want to load them before user gets there. So you could just not mess up with native browser loading in the first place. Because all those requests and client side calculations will add up.
When you have image heavy content please load an image when I'm one or two page heights before the image. This way when I get there it will already be there. You could then just use regular single background placeholders, because I (and I would believe that you also) never intend to see them in the first place.
Re: Using SVG as image placeholders
#103Clever, but I'd love to see browser support for FLIF make this kind of thing irrelevant. > FLIF is lossless, but can still be used in low-bandwidth situations, since only the first part of a file is needed for a reasonable preview of the image. > A FLIF image can be loaded in different ‘variations’ from the same source file, by loading the file only partially. This makes it a very appropriate file format for responsi…
Do we need a new format? I remember jpeg's had this kind of functionality back in the days of dialup, all the patents for that should have expired long ago.
Are you sure you're not thinking of interlaced GIF? That was used pretty widely for images in the days when the processing for jpeg could actually be serious work for a pc.
Re: Using SVG as image placeholders
#104Clever, but I'd love to see browser support for FLIF make this kind of thing irrelevant. > FLIF is lossless, but can still be used in low-bandwidth situations, since only the first part of a file is needed for a reasonable preview of the image. > A FLIF image can be loaded in different ‘variations’ from the same source file, by loading the file only partially. This makes it a very appropriate file format for responsi…
>Clever, but I'd love to see browser support for FLIF make this kind of thing irrelevant. No, it will not make much difference. You rarely need lossless for anything but stuff like UI elements, which to begin with should not be drawn as PNGs if they are simple graphics that can be drawn as SVG
Rendering SVG is considerably slower than PNG. If you know the target's display DPI, generating PNGs from the source SVG ahead of time is usually the better choice.
Re: Using SVG as image placeholders
#105(Developer of Primitive here.) Love seeing people use my software in different ways! If this looks interesting to you, try it out: https://primitive.lol/ https://github.com/fogleman/primitive Also, I made a Twitter bot that posts samples every 30 minutes based on "interesting" Flickr photos using randomized Primitive settings: https://twitter.com/PrimitivePic
Awesome! Are you aware of ports to any other language?
Re: Using SVG as image placeholders
#106(Developer of Primitive here.) Love seeing people use my software in different ways! If this looks interesting to you, try it out: https://primitive.lol/ https://github.com/fogleman/primitive Also, I made a Twitter bot that posts samples every 30 minutes based on "interesting" Flickr photos using randomized Primitive settings: https://twitter.com/PrimitivePic
Awesome! Are you aware of ports to any other language?
I have a JS "port" (not a 1:1 reimpl): https://github.com/ondras/primitive.js
Re: Using SVG as image placeholders
#107This looks interesting. Here's a shameless plug if somebody needs tracing:
ImageTracer is a simple raster image tracer and vectorizer that outputs SVG, 100% free, Public Domain.
Available in JavaScript (works both in the browser and with Node.js), "desktop" Java and "Android" Java:
https://github.com/jankovicsandras/imagetracerjs
Re: Using SVG as image placeholders
#108Earlier quoted context omitted.
Do we need a new format? I remember jpeg's had this kind of functionality back in the days of dialup, all the patents for that should have expired long ago.
Are you sure you're not thinking of interlaced GIF? That was used pretty widely for images in the days when the processing for jpeg could actually be serious work for a pc.
Possibly, I just remember being a grateful teenager when my adult images loaded progressively.
Wouldn't gif have been a poor format for that even with progressive loading?
Re: Using SVG as image placeholders
#109Looks interesting. Any interest in building a SaaS model on top of this?
Re: Using SVG as image placeholders
#110A real game changing technique! Why? To use progressive JPG, you have to pre-recode (if you don't have money to dish out for FPGA to recode on the fly) and store recoded images. With this, you don't have to alter the original image. My favorite method was to use img tag with blur, you programmatically add image, then you wait when, say 10% of this it is loaded, and abort the request. It will stay that way. When you n…
>To use progressive JPG, you have to pre-recode (if you don't have money to dish out for FPGA to recode on the fly) and store recoded images. Not sure why progressive JPG isn't the default. It's not any larger.
The rules of thumb seem to be that (a) for JPEGs under 10kB progressive may actually be larger and (b) for mobile devices the extra effort (CPU, memory) of progressive decode may be significant eg in taking time away from other parts of page rendering.