kaioa.com

*squish*

SWF gaiden (side story)

This is some kind of spin-off from my previous mini project. As I said back then Deflate is everywhere. SVGZ files are just gzipped SVGs for example. I thought it would be nice to have some specific tool for SVGZs, but since it's just GZip I decided to generalize it a little bit.

It's basically a logical sub step on the way to the next SWF re-compression utility. It spawns several worker threads which invoke different ZIP utilities with different switches. E.g. with 2 cores there are 2 worker threads by default, which means it can keep up to 12 cores busy with the current default configuration (it contains 12 tasks). At the end the smallest Deflate stream is extracted and put into a GZip file.

The tool is similar to PNGOUT, OptiPNG, or PNGCrush insofar as it clearly puts the priority on size over time — except that it's for GZ/TGZ/SVGZ/etc. files instead of PNG.

Hrrrrrngh!

Intro

With web games you want hits — lot's of hits. A million per month or more if possible. Of course this means lots of traffic. While broadband became faster and cheaper during the last couple of years, traffic is still somewhat expensive. In order to get a nicer cost/income ratio there are apparently two options: reduce the costs and/or increase the income.

As you might have guessed I'm about to tackle the former with brute processing power. If you reduce the file size by 1% every 100th served file is free. With 5% it's every 20th file and with 10% every 10th file. If the price for that are only a few minutes of processing power it looks like a really good deal, doesn't it?

Cut the size in half

Why

I was tired of waiting for this to happen. It's simple stuff and the effect is pretty big if your content primarily consists of text. Well, it's not like this affects the text - that's already compressed by Drupal if you allow it to do so - what I mean is the compression ratio. If you serve megabytes of images, sound, and video, shrinking those few percent of JS and CSS won't have much of an effect.

However, if your site is more like this one you might be able to cut the size of the site in half. For people with a non-primed cache, that is. That's a really big plus if you get a sudden surge of visits. Nowadays the typical resource usage pattern seems to go from one spike to the next with rather little usage in-between. Take a look a Esoteric Curio's excellent article if you're interested in some more details.

As I previously pointed out even your regular visitors often won't have a primed cache, because the cache is simply too small for today's bloaty web. By the time they visit your site again the cache was already overwritten most of the time. Server-sided caching and compression to the rescue!

As I mentioned earlier this new version of the flash player supports MPEG-4 AVC (H.264) and High Efficieny AAC (HE-AAC). Check the press release for some details. Well, there isn't much of a surprise there.

What's surprising tho is that it was released for Windows, Mac OS X, Linux, and Solaris simultaneously. Way to go Adobe! :)

Grab it while it's hot!

Update: There seems to be some issue with Adobe's mirrors. Right now it claims it would be 9,0,115,0 (the version I spoke of), but the version I'm actually getting is 9,0,47,0. I guess I have to wait a bit.

Update2: OK. Seems to work now. Unfortunately the "lossless" H.264 mode from ffdshow tryouts still doesn't work. It's a shame really, since that one would have been perfect for screencasts.

Introduction

SVGs can be optimized for three different things. File size, rendering speed, and editing. For the most part you want to optimize for editing - especially with complex drawings. Towards the end you may want to lean toward the 2 other goals tho.

Optimizing for rendering speed is very interesting for devices with limited capabilities such as cellphones or PDAs. Things to keep an eye on are node counts, overdraw, clones, clipping, masking, gradients, and even simple stuff such as strokes. Nokia published some pretty decent guide (PDF) on this topic.

Optimizing for size shares a few aspects of the speed optimization. Keep the node count as low as possible, combine paths where possible... that kind of thing. However, you completely ignore overdraw, and you use clones/clipping/masking/stroke/gradients all over the place. It's certainly lot more entertaining than speed optimizations and it also won't affect editing speed that much. That's why I'll experiment with that.

Over at the other post I mentioned a few possible optimization strategies. Reducing accuracy is one of the more obvious ones. It's a pretty well known technique, but so far I didn't really like that idea.

The problem is specifying the amount of digits is awfully indirect and lacks any context. As a user you don't really want this or that many digits, but pixel accuracy up to a specific size. Eg for web usage (with viewBox attribute) you may want something like pixel accuracy up to a width of 1600 pixels or the size of your canvas.

This is a simple lossless tweak, which can save a few bytes here and there. Close Inkscape if it's running then open preferences.xml (C:\documents and settings\<you>\application data\Inkscape or ~/.inkscape/) with a text editor and search for "inlineattrs".

You should see something like:

<group
   id="svgoutput"
   usenamedcolors="0"
   numericprecision="8"
   minimumexponent="-8"
   inlineattrs="0"
   indent="2" />

Change the value of inlineattrs to 1. Feel free to change other values, if you know what you're doing. (Make a backup if you don't.)

Now you get slightly more compact markup.

Before:

<g
   inkscape:label="Layer 1"
   inkscape:groupmode="layer"
   id="layer1">
  <path
     style="[...]"
     d="[...]"
     id="rect2204"
     sodipodi:nodetypes="ccccc" />
</g>

After:

<g inkscape:label="Layer 1" inkscape:groupmode="layer" id="layer1">
[...]

Wow that's some awesome news. Just a few hours ago I thought how nice it would be if Flash would support H.264. And there it is! :)

The compression ratio of the lossless codec (Screen Video/Screenshare) is sorta bad, Sorenson Spark (a H.263 bastard) looks really bad and VP6 is a major pain to get working (and it isn't really all that great). H.264 (2pass), however, works really well for screencasts. You get very good compression and almost perfect looks. It's currently the best choice for the last mile.