A Shock Of The Ordinary

Last night I watched a scene in an episode of the second season of Downton Abbey in which two sympathetic characters visit a church together and pray. That's it --- no plot devices, no subtext, no ulterior motives, no mockery; it was just showing what some ordinary people sometimes do. I was shocked, because I basically never see Christians just being Christians in movies or television. Soon afterward I was flipping through the catalogue of the New Zealand International Film Festival, and there it seems one is more likely to see a serial killer being portrayed sympathetically than a Christian. This is not surprising --- "it's 'the world', stupid", as someone once put it to me --- but it's sad nonetheless. No wonder people have such distorted ideas about us.

Happy Days

I gave permission from a writer to use an old wedding photo of ours for a story.

We got married in Sydney because that's where my wife was living at the time --- I was at CMU in Pittsburgh. We had the ceremony in the morning and the reception in the evening so we had several hours in between to just roam around Sydney taking photos and having a good time. I think a lot of weddings are for the benefit of guests and the couple doesn't have such a great time, but we bucked that trend. It was definitely one of the best days of my life.

A lot of things have changed since then. Our marriage has had its issues but I'm very thankful that in most ways it's better than it's ever been, as we keep learning to be better at being married. We'll need to, for the challenges ahead!

Avoiding Copies In Web APIs

The Web platform has matured to the point where avoiding data copying is often an important optimization to reduce running time and memory usage. Avoiding data copies often requires careful API design. The Web has two facilities that are very useful for writing such APIs: Blobs and ArrayBuffer neutering.

A Blob is a chunk of generic immutable data, optionally with a MIME type. Its contents are not directly byte-addressable, enabling browsers to easily offer multiple implementations of Blob under the hood. For example, in Gecko we support Blobs backed by in-memory buffers, Blobs backed by files, and Blobs that reference lists of other Blobs they are the concatenation of. Because Blob contents are immutable, it's easy for multithreaded or multiprocess browser implementations to safely share Blob contents in any situation without copying (including, for example, Blobs being passed between Workers via structured cloning). Any Web API dealing with generic data chunks that don't need to be byte-addressable or easily mutable should probably use Blobs, or at least support Blobs as an option.

ArrayBuffer is part of the Typed Arrays spec; it represents main-memory data that is directly addressable and mutable. Because preventing in-memory data races is an important principle of the Web platform, ArrayBuffers cannot be directly shared between Workers. Therefore we added to the Web the ability to transfer ownership of an ArrayBuffer's data between workers (and the main thread) via the Transferables abstraction. An ArrayBuffer is normally represented as a small JS object containing an internal pointer to a (usually much larger) buffer containing its elements. When an ArrayBuffer is transferred from one thread to another, the ArrayBuffer on the origin thread is neutered --- i.e. its length becomes zero; its element buffer is detached and ownership transferred to the destination thread; and on the destination thread a new ArrayBuffer object is created wrapping the transferred element buffer. The contents of the element buffer are not copied.

ArrayBuffer neutering is potentially useful for more than just transferring ownership between Workers. Some Web API methods take ArrayBuffers or typed arrays as parameters, and have to copy the data internally for later use. For example, WebGLRenderingContext.bufferData has to validate its ArrayBuffer parameter's contents and copy the data for later use --- otherwise the caller could modify the ArrayBuffer after the bufferData call has returned, and defeat any validation that was performed. If it's helpful for performance, we can add a version of bufferData that neuters its ArrayBuffer parameter and takes ownership of the data instead of copying it.

Web Audio is an interesting case. Web Audio AudioBuffers contain ArrayBuffers containing audio samples. AudioBuffer samples are made available to an audio processing thread. The question is, what happens if those sample ArrayBuffers are modified by the main thread while the audio processing thread is using them? If the memory is naively shared, the answer is "data races", which are unpopular with many people (including me). One way to fix this without adding copying is to allow an AudioBuffer to neuter its ArrayBuffers, taking ownership of their element buffers and making them immutable so no copying is needed but there's also no possibility of data races.

When designing new Web APIs, if copy avoidance is important, we should keep ArrayBuffer neutering and Blobs in mind as possible solutions.

Movie Picoreviews

I've just returned home from another Bay Area trip for the LEAD program. I also met up with Dirk Schultze and some other Adobe developers for some work on SVG/CSS filters.

Because of the Asiana crash at SFO, my flight to SF was delayed by ten hours and became a daylight flight, so I watched five movies on the way there. I watched two on the way back. The movie haul this month was pretty good actually.

• Life Of Pi: Brilliantly executed but not all that interesting.
• Seven Psychopaths: Slightly above average. A lot more interesting than the title would suggest.
• Stoker: Above average thriller.
• Argo: Pretty good, apart from the gratuitous slander against New Zealand.
• Trance: Somewhat absurd but interesting thriller.
• Side Effects: Pretty good mystery/thriller.
• Dangerous Liasons (2012 Chinese version): Pretty good, but I'm a sucker for Chinese period drama, not to mention Zhang Ziyi and Cecilia Cheung.

Contributing Advocacy

Sometimes we make changes that are strongly justified but inevitably annoy some of our users. The Firefox 22 change to be aware of UI scaling on Windows is a good example. Some of the most helpful contributions I've see from community members recently are patient explanations to complaining users why we made changes and what they can do about it. I'm particularly thankful because interacting with upset users is draining for me --- I need to save my emotional energy for interactions on Web standards mailing lists :-).

The same goes for our volunteers who work with Web developers. Thanks to all of you. Please keep it up!