Skip to content

Comment on Show HN: Using SVG to Shrink Your PNGs

Comments

I think I have an idea on how to support IE8 and do this without SVG.

1. Create a JPG of the can and trim the edges off completely

2. Create a PNG of the can and remove the insides completely, leaving only the edges

3. Overlay the JPG on top of the PNG using CSS absolute positioning or background+foreground image or similar

Since the JPEG comprises only the inner part of the image, it doesn't affect anything. The PNG comprises the outer edges of the image and you get the desired transparency on the edges.

Good idea! To go further, you could cut the PNG into four strips (top, bottom, left, right) so the browser doesn't have to store the enormous rectangle of transparent pixels making up the insides of the PNG.

The few bytes you'd save on the png would be lost on the few bytes of additional markup you'd need in your html.

The browser still has to store that uncompressed empty area though, so it would use more memory and probably take slightly longer to paint on a slow device.

I was under the impression that PNG is actually quite good at compressing areas of a singular solid color (or in this case solid transparency). It just fails at every-pixel-is-different cases, where JPG is better.

Furthermore, I'm pretty sure a slow device would take longer to paint four separate images due to the overhead of having four of them.

In order to draw the PNG, the browser has to decode it, including the transparent pixels. I'm also pretty sure (though I haven't tested this) that the overhead of painting four smaller images is negligible in comparison to the cost of blending the entire center area.

Many sites are very bad about this, e.g. this sprite sheet from linkedin: https://static.licdn.com/scds/common/u/img/sprite/sprite_glo... which, when decoded, takes up ~9MB of almost entirely empty memory. Check out the "Optimizing Web Content in UIWebViews and Websites on iOS" talk on https://developer.apple.com/videos/wwdc/2012/ for more info about not wasting memory on mobile web sites.

Furthermore, I'm pretty sure a slow device would take longer to paint four separate images due to the overhead of having four of them.

Back in the old days of 2D game development, some games would use a technique called "dirty rectangles" to repaint selected areas of the screen that had changed. Windowing systems like X did/do something similar with "damage" or "expose" events (can't remember the exact name).

It's because the logic to handle many separate small rectangles is less expensive than the loop and memory bandwidth to paint one big one.

Nitrogen's point is that most (all?) browsers decompress the image in memory.

Yes, the website seems to waste a lot of resources: 66 requests, 1.9 MB Specially since it is so minimalist. The beer file (can-top.jpg) is 260kb, could easily shrink to half of that without losing too much quality.

Also, some code left over:

console.log("toto");

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.