Category Archives: Fyre


New MacBook Pro + Fyre

Back when I bought my last Mac: USB and the Playstation 2 were new, Altivec and shiny plastic were in, and fans were almost starting to line up for the first Harry Potter movie. Oh, and warrantless wiretapping was still illegal. So, Apple, I guess it’s time to put all those hardware failures behind us and see if this relationship can work.

I’ve actually had a lot of fun hacking on Mac OS at work while developing VMware Fusion. Working on such a low-level software project, you see a lot of the ugliest parts of any OS. And there’s certainly a lot inside Mac OS that scares me. But there’s also a lot of cool technology in there. And best of all, I don’t have to futz with my ALSA settings for an hour if I want to watch a YouTube video. Win!

I’d been thinking about upgrading my aging Thinkpad to a 15″ MacBook Pro when it finally kicks the bucket. But darnit, those things are too reliable. So I needed a different excuse. I think it finally boiled down to:

  1. Faster CPU (and 6MB L2 cache.. drool…)
  2. More memory (4GB standard in a laptop. We truly do live in the future.)
  3. Runs Mac OS, Linux, and Windows- so I can develop software for all three
  4. Ooh, shiny!

It arrived this morning, and indeed it is quite shiny. I really do like the new Unibody design- and the large trackpad surface with pseudo-button is actually quite a lot nicer than the standard touchpad on my Thinkpad. (I’ll see how long I can resist the urge to do some low-level poking around in the touchpad, to see how its multi-touch protocol works…)

I think I’m a bad Mac user though. Just about the first two things I did were to install the Ubuntu 9.10 RC, and Windows 7. Then I had to continue my tradition and render a new background image:

Rendering some wallpaper for my MacBook Pro

This is using Fyre‘s cluster rendering support. The GUI and one rendering node are running in a 2-VCPU 64-bit virtual machine on my MacBook Pro. I have two more nodes running on a desktop Athlon64 machine running Linux natively. The total speeds here are pretty impressive- comparable to what David was able to get from running cluster nodes on every machine in one of the CS labs back in college. Isn’t Moore’s Law great? (And I’m sure the 6MB L2 cache helps :))


Flightaware route histogram

Flightaware + Fyre:

The above image is part of a histogram generated from Flightaware’s 24-hour time lapse. Click the link for the uncropped version. The original video is a Quicktime wrapper around individual PNG frames. I used mencoder to strip off the Quicktime wrapper, then a small Python script split the video streams into individual frames, decompressed them, and plotted a histogram of each red dot. The script generated a data file which was rendered using a patched version of Fyre 1.0 SVN.

Oversampling in Fyre

Despite Fyre 1.0 being “completely done” for a while now, I have to nitpick it occasionally. I recently composed an image which brought out a particularly bad oversampling bug in Fyre.

Fyre implements antialiasing using an oversampling technique, much like FSAA on modern video cards. In Fyre 1.0.0, we just chop each pixel into an even 2×2, 3×3 or 4×4 grid of subpixels. Making an analog signal processing analogy, it increases the sampling frequency and adds a low-pass filtering stage after the samples are taken. There is still the potential for very high-frequency features in the original signal to alias, and produce undesirable patterns in the resulting output.

In the current development version of Fyre 1.0, I’ve added ±1 subpixel of spatial noise prior to sampling, which gives us the missing low-pass filter that should keep us below the Nyquist limit. Intial results look good:

Before: Fyre 1.0.0 release, 3x gamma-corrected oversampling on a regular grid

After: Fyre 1.0 SVN, 3x gamma-corrected filtered oversampling

January 2006 Update


It’s easy for me to see Fyre as a ‘dead’ project these days- the existing codebase was declared ‘done’, and we moved on to a new architecture dubbed Fyre 2.0. In some ways this rewrite has suffered from second system effect, and the code hasn’t been touched in a while. But, I think we all agreed this was necessary. Fyre 1.0 really was a great release, and it really did everything we felt it should do considering the project’s scope.

Anyway, it’s really heartwarming when I come across an enthusiastic user of Fyre on the interweb, who’s posted some renderings of their own. It’s even cooler to find someone who’s implemented their own Distributed Chaotic Image Renderer after being inspired by Fyre.

Now that Firefox 1.5 is commonplace, I might as well mention my old Javascript De Jong renderer. It’s a great example of why the <canvas> element is largely orthogonal to SVG.

Home Theater

My traditional method of playing DVDs at home would be to boot up my HTPC and play them via Freevo. In concept this was great, but the picture quality left much to be desired- lots of horizontal ‘wiggle’ due to noisy sync signals from my video card’s component out, and the video was getting scaled at least twice.

Yesterday, while wandering the shopping megaplex that is Santana Row, I finally picked up a hardware DVD player: An LG LDA-511, on sale for $110 after rebate. I’m just blown away by how much hardware you get for that price these days: slot loading drive, HDMI output, upscaling to any HDTV resolution, DivX/MPEG4/JPEG/MP3/WMA playback, memory card slots… The picture quality is great, and it will even play a lot of music and video directly off of my existing DVD-R discs. My one complaint so far is that the memory card reader is excruciatingly slow. It’s a good thing I doubt I’ll ever have a use for that feature.


I came across the Django project recently. This is an incredibly spiffy mod_python-friendly web framework, which includes a template system and a rather cute object-relational mapper. Since I’ve been wanting to get CIA‘s web frontend away from Twisted and onto mod_python for a while now, this looks like a great opportunity to simultaneously do away with Nouvelle.

So, I’ve started a branch for what’s sure to be a heavy-handed hack and slash partial rewrite. The biggest issue with splitting the HTTP frontend into multiple mod_python processes, however, is the ruleset storage. Currently, CIA just loads all rulesets from the database on startup, compiles them a bit, then scans them linearly every time a message is delivered. This is both RAM-hungry (about 8MB) and very CPU inefficient. My current strategy is to actually compile the rulesets into an SQL table such that the slowest and least scalable aspects of message filtering can all be done efficiently within the SQL server.


I’ll procrastinate after I pick your browser up off the floor

I’ve been making slow progress on packing today- got all my books boxed up, along with many of my less fragile electro-widgets and such. This type of behaviour leads to procrastination, naturally.

I’ve been running the Deer Park Alpha 2 release of Firefox for a couple days. It does seem to be faster at DHTML, though I don’t have any of the really heavy-duty Javascript I wrote for Destiny M&M handy for benchmarking purposes. The coolest features destined to end up in Firefox 1.1, from my point of view, are SVG support and the “canvas” element.

Canvas is a very misunderstood HTML extension. It’s a new element that Apple invented mostly to make it easier to implement Dashboard. That part of the story is a little silly, and results in a lot of SVG advocacy and a lot of potential users suggesting to Apple places where they might shove their nonstandard hacks.

Well, it turns out that Canvas is indeed a standard- or at least a standard draft. Furthermore, it’s been implemented by the Gecko team, and happily runs in Deer Park. If you read the API, you notice that Canvas and SVG are really solutions to two completely different problems. SVG is a very complicated and very featureful scene graph built on XML, whereas Canvas looks more like a minimal vector drawing and raster compositing library for JavaScript. Canvas uses a simple immediate-mode interface for rendering to a bitmap, which makes it ideal for games or special effects, or for client-side image manipulation applications.

Canvas is so cool I had to abuse it. A while back I tried to render the Peter de Jong map in Javascript, basically making a very slow and crippled but very portable version of Fyre. Anything scene-graph-like, such as your usual DHTML tactics, would be disgustingly slow and memory-intensive. I ended up using Pnglets, a Javascript library that encodes PNG images entirely client-side. This worked, but was only slightly less disgustingly slow.

Anyway, the result of porting this little demo to Canvas was pretty neat. It’s still no speed demon, but it’s very impressive compared to the Pnglets version. It’s fast enough to be somewhat interactive, and it has at least basic compositing of the variety that Fyre had before we discovered histogram rendering. If you have Deer Park, Firefox 1.1, or a recent version of Safari you should be able to run the demo yourself.