https://github.com/mahonnaise/svgjng/

    java -jar svgjng.jar <rgba image> <svgz file name> [color quality] [alpha quality]

Gallery: http://kaioa.com/b/1102/svgjng/index.html

"SVGZ (auto)" means default parameters. I.e. just:

    java -jar svgjng.jar foo.png foo.svgz

I kinda lost interest in this project, because, back then, it actually didn't work. The SVG spec had to be fixed first and Chrome didn't even display those images at all due to a bug.

Basically, the problem with the spec was that it required the masks to use some nonsensical color space. Half of the implementations didn't, because it didn't make any sense and because the wording was extremely confusing.

Anyhow, the spec got changed and browsers started to implement this newer version of the spec. Nowadays, it actually does work.

Well, that's basically the whole story. That's why there isn't an article which promotes it. There were showstoppers which made it completely unusable.

I ended up trying a whole bunch of different ways to solve the problem, one of which was very similar to this method. As the author points out however, this does not work in IE8 among other things, and at the time this was a requirement... I ended up using different combinations with different levels of quality depending on the browser, a true nightmare which ended up eating a third of the budget for no justifiable reason.

In any case, the fact that we have to go through tricks like this to achieve both transparency and decent compression is pretty disappointing. But what I find maybe even sadder is the amount of resources we sometimes spend on things which seem incredibly frivolous, to me anyway. I'm sure Sapporo have pretty deep pockets, which the author rightly took advantage of, but that doesn't make it any less superficial.

Seems a bit unfair as a comparison. He is talking about a simple trick to save time and money and you compare it to a different expensive mistake.

The visual results may be the same, but it's not necessarily the case that he rightly took advantage of anyone.

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.

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.

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.

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.

Also, some code left over:

console.log("toto");

The exceptions were the assets where the alpha channel was used for picking (e.g. to detect drag and drop on a puzzle piece). In that case the settings were overriden for that particular asset to something like PNG8 (which also compresses fine since most alpha masks are mostly black and white with only some grey pixels at the edges due to antialiasing).

That and auto-cropping the assets - the engine has the concept of a "virtual canvas" so we could have full-screen transparent PNGs with only a small button in it, which the pipeline would reduce to the area that had the contents; but on the engine side you just treated it as a full-screen image, so you could place it at (0, 0) and the button would still appear wherever the artist had put it.

We got crazy reductions in file size using this one weird trick! Good times.

IE 10 (which offered a richer SVG experience) wasn't available until Sept 2012. Since then 10+ has gained market share, but there are still a lot of XP and Vista users causing problems (or pirate Windows 7 users who cannot install SP1).

SVG is actually really cool. About damn time it is getting usable across the board. Hopefully two years from now using SVG will be a "no brainer" in terms of backwards compatibility.

[0] https://en.wikipedia.org/wiki/Scalable_Vector_Graphics#Nativ...

Case in point: different browsers handle adding an SVG filter onto a DOM element / SVG parent element / SVG child element very differently (in Firefox, if an SVG element that holds a filter is display:none, and you apply that filter to an element that is visible, the filter not only is not applied - but the element it is applied to also becomes display:none). Unfortunately, it's also not one of those things you can feature detect for: out come the user agent tools again...

But yes, SVG is very very cool. For our use case, even IE9 is fairly up to par with it.

https://tinypng.com/ https://github.com/foobaz/lossypng