Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using SVG as image placeholders

medium.com

Post reply on HN
Print view View original

21–30 of 139 posts

Re: Using SVG as image placeholders

#21

Post by rcarmo »

I love the visual effect, but I have to wonder how much CPU/GPU is entailed in rendering 10-50 triangles, blurring them and rendering the result to the page canvas vs. loading a pre-blurred image (that might be a "tiny" progressive JPEG), so I'd probably try to do this server-side first

(edit for clarity: my site currently generates <12Kb blurred placeholders from high-def photos and only loads visible images to be more mobile-friendly, and I worry about client-side rendering impacting battery life).

Re: Using SVG as image placeholders

#22

Post by baybal2 »

nathan_long wrote: post #16
baybal2 wrote: post #11

Earlier quoted context omitted.

>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

How will FLIF "not make much difference" here? Suppose we're talking about a profile image. The full, lossless file is 40KB. The video on the FLIF site ( http://flif.info/index.html ) shows a blurry-but-useful preview being displayed with the first 0.25% loaded (and possibly before). In this case, that's 100 bytes, which is a fraction of a single TCP packet. Don't need the full resolution of the 40KB lossless file? O…

Maybe, people usually just recode avatars to low-res JPGs

Re: Using SVG as image placeholders

#23

Post by untog »

fenwick67 wrote: post #2

This is the kind of thing that seems really neat (I love computer generated art) but ultimately the user experience isn't any better than just a solid rectangle, and you're sending like 1kb more per image to show the placeholder.

I'm more concerned about CPU time on mobile devices - rendering SVGs then blurring them is surely more intensive than other options.

Not saying it isn't worth it, but AFAIK no-one has profiled this.

Re: Using SVG as image placeholders

#25

Post by mcphage »

nathan_long wrote: post #9

Clever, 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…

> browser support for FLIF make this kind of thing irrelevant

I'm not sure it would. The nice thing about a lot of these SVG options (or even the smaller images as well), is that they can be embedded into pages. So not only do you see the image faster, you also reduce the number of remote file fetches. FLIF sounds like you'd still have to hit another server to see anything, even if the thing you see would display before it finishes loading.

Re: Using SVG as image placeholders

#26

Post by derefr »

baybal2 wrote: post #12
minimaxir wrote: post #8

Another fun thing to do with using SVG-as-images in the browser is easy animation of the SVG, using Primitive (for example) as noted in the article to convert an image into SVG shapes, plus a tool like Vivus ( https://maxwellito.github.io/vivus/ ) or Snap.svg ( http://snapsvg.io ) to animate each shape of the SVG. Here’s a demo I made using Primitive + Vivus: http://minimaxir.com/2016/12/primitive/

SVG animation is amazing, but as a person who made work with in-browser animation and visualization my breadwinner, I can say that usage of JS for that is a huuuuuge downside Effectively, you have to rewrite a big part of actionscript functionality into your browser to do really simple things It is greatly regrettable than browsermakers have thrown out all declarative animation features, and never thought of improvin…

Is “declarative SVG animation scripting” really a primitive API you need the browser to support directly? “Rewriting a big part of Actionscript functionality” seems like the job of a JS animation framework, not the browser. Like the ones that animation tools that previously compiled to Flash (e.g. Adobe Animate itself) use.

Re: Using SVG as image placeholders

#27

Post by AnkhMorporkian »

rocky1138 wrote: post #10
AnkhMorporkian wrote: post #5

Earlier quoted context omitted.

I disagree. If you have a user on a very slow connection on an image heavy site, the user experience will be enhanced significantly. Depending on how you implement it, you might even save them bandwidth. No interesting content for them in the current viewport and they scroll past the placeholders/go to the next page? Cancel the XHR requests you made for the full-size thumbnails/images and start anew.

I agree with GP. Personally, I hate websites that show a blurry version of an image before the final one loads. It plays with my eyes. I have to look away and peek to see if it's done before I can read on. I wish there was a way to disable this functionality.

I didn't mean to refer to blurred images, but the unblurred outline SVGs in this article. I think the blurred ones are somewhat pointless too. The unblurred versions give you actual information as to what the image is. For instance, the sneakers image; if I didn't care about sneakers, I'd be likely to just scroll past it. In the blurred version, I might not be able to tell that they're sneakers.

Re: Using SVG as image placeholders

#28

Post by klodolph »

nathan_long wrote: post #9

Clever, 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…

The problem with FLIF here is that it's not remotely competitive when you're using a lossy format for both the low-quality and high-quality versions, which is the most common case for photos. UI elements tend to be small, so it doesn't matter.

In most cases if you get more bandwidth which you could spend on using a lossless FLIF, you would get better subjective quality by using a higher resolution JPEG at the same file size.

Re: Using SVG as image placeholders

#29

Post by nathan_long »

baybal2 wrote: post #22
nathan_long wrote: post #16

Earlier quoted context omitted.

How will FLIF "not make much difference" here? Suppose we're talking about a profile image. The full, lossless file is 40KB. The video on the FLIF site ( http://flif.info/index.html ) shows a blurry-but-useful preview being displayed with the first 0.25% loaded (and possibly before). In this case, that's 100 bytes, which is a fraction of a single TCP packet. Don't need the full resolution of the 40KB lossless file? O…

Maybe, people usually just recode avatars to low-res JPGs

FLIF makes re-encoding unnecessary. http://flif.info/responsive.html

> for every image, only one file is required, ever. The optimization can happen entirely on the client side.

> 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 responsive web design. Since there is only one file, the browser can start downloading the beginning of that file immediately, even before it knows exactly how much detail will be needed. The download or file read operations can be stopped as soon as sufficient detail is available, and if needed, it can be resumed when for whatever reason more detail is needed — e.g. the user zooms in or decides to print the page.

Re: Using SVG as image placeholders

#30

Post by lewisl9029 »

AnkhMorporkian wrote: post #5
fenwick67 wrote: post #2

This is the kind of thing that seems really neat (I love computer generated art) but ultimately the user experience isn't any better than just a solid rectangle, and you're sending like 1kb more per image to show the placeholder.

I disagree. If you have a user on a very slow connection on an image heavy site, the user experience will be enhanced significantly. Depending on how you implement it, you might even save them bandwidth. No interesting content for them in the current viewport and they scroll past the placeholders/go to the next page? Cancel the XHR requests you made for the full-size thumbnails/images and start anew.

Yep, the main use case I imagine for something like this would be to show a blurred/tastefully-rendered <10 KB SVG _instead_ of a multi-megabyte hero JPG that still ends up looking horrible on 4K screens.
Post reply on HN