Tag Archives: fyre

4052448504_af691980e5_b

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 :))

fvwz

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.