Thursday, 20 February 2014

3 Mile Limit

Tonight I went the the premiere of the movie 3 Mile Limit. It's a New Zealand movie based on a true New Zealand story, the story of how in the 1960s four young men set out to break the government's monopoly on radio broadcasting by setting up a "pirate" radio station on a boat in international waters in the Hauraki Gulf. Lack of funds and government obstruction made their project extremely difficult but they were ultimately successful. This story is special to me because my father, Denis "Doc" O'Callahan, was one of the four and I am immensely proud of him. My father played an important role in the project, being the original radio engineer and also the first skipper of the boat, the Tiri. The movie's "Morrie" character is based on him.

You can tell from the trailer that the movie's a bit cliched, but I enjoyed it more than I expected. I found the production design evoking 1960s Auckland quite lovely --- parts of it reminded me of early childhood memories, and some parts remind me of Auckland today. A lot of the story has been rewritten for dramatic purposes, and the changes mostly work. The core theme of young rebels fighting to bring rock music to the public is completely true. The movie opens on March 6 and I hope it has a good run.

Wednesday, 19 February 2014

World Famous In Newmarket

The Newmarket Business Association has made a series of videos promoting Newmarket. They're interesting, if a little over-produced for my taste. Their Creativity in Newmarket video has a nice plug for the Mozilla office. Describing our office as a "head office" is a bit over the top, but there you go.

Monday, 17 February 2014

Implementing Virtual Widgets On The Web Platform

Some applications need to render large data sets in a single document, for example an email app might contain a list of tens of thousands of messages, or the FirefoxOS contacts app might have thousands of contacts in a single scrolling view. Creating explicit GUI elements for each item can be prohibitively expensive in memory usage and time. Solutions to this problem often involve custom widgets defined by the platform, e.g. the XUL tree widget, which expose a particular layout and content model and issue some kind of callback to the application to populate the widget with data incrementally, e.g. to get the data for the currently visible rows. Unfortunately these built-in widgets aren't a good solution to the problem, because they never have enough functionality to handle the needs of all applications --- they're never as rich as the language of explicit GUI elements.

Another approach is to expose very low-level API such as paint events and input events and let the developer reimplement their own widgets from scratch, but that that's far too much work.

I think the best approach is for applications to dynamically create UI elements that render the visible items. For this to work well, the platform needs to expose events or callbacks informing the application of which part of the list is (or will be) visible, and the application needs to be able to efficiently generate the UI elements in time for them to be displayed when the user is scrolling. We want to minimize the "checkerboarding" effect when a user scrolls to a point that app hasn't been able to populate with content.

I've written a demo of how this can work on the Web. It's quite simple. On receiving a scroll event, it creates enough items to fill the viewport, and then some more items within a limited distance of the viewport, so that browsers with async scrolling will (mostly) not see blank space during scrolling. Items far away from the viewport are recycled to reduce peak memory usage and speed up the item-placement step.

The demo uses absolute positioning to put items in the right place; this is more efficient than moving elements around in the DOM to reorder them vertically. Moving elements in the DOM forces a significant amount of restyling work which we want to avoid. On the other hand, this approach messes up selection a bit. The correct tradeoff depends on the application.

The demo depends on the layout being a simple vertical stack of identically-sized items. These constraints can be relaxed, but to avoid CSS layout of all items, we need to build in some application-specific knowledge of heights and layout. For example, if we can cheaply compute the height of each item (including the important case where there are a limited number of kinds of items and items with the same kind have the same height), we can use a balanced tree of items with each node in the tree storing the combined height of the items to get the performance we need.

It's important to note that the best implementation strategy varies a lot based on the needs and invariants of the application. That's one reason why I think we should not provide high-level functionality for these use-cases in the Web platform.

The main downside of this approach, IMHO, is that async scrolling (scrolling that occurs independently of script execution) can occasionally and temporarily show blank space where items should be. Of course, this is difficult to avoid with any solution to the large-data-set problem. I think the only alternative is to have the application signal to the async scroll thread the visible area that is valid, and have the async scroll thread prevent scrolling from leaving that region --- i.e. jank briefly. I see no way to completely avoid both jank and checkboarding.

Is there any API we can add to the platform to make this approach work better? I can think of just a couple of things:

  • Make sure that at all times, an application can reliably tell which contents of a scrollable element are going to be rendered. We need not just the "scroll" event but also events that fire on resize. We need some way to determine which region of the scrolled content is going to be prerendered for async scrolling.
  • Provide a way for an application to choose between checkerboarding and janking for a scrollable element.

Friday, 7 February 2014

Mozilla At Motuihe

Today was Waitangi Day in New Zealand, a public holiday. Since we haven't had our usual annual Mozilla office excursion, several people from the Mozilla office decided to go to Motuihe Island for the day with families/partners. Motuihe is a fairly small island between Waiheke Island and Auckland, recently cleared of predators and subject to a large reforestation and native bird repopulation project. In particular, little spotted kiwi have been reintroduced. This means I can see, from my desk, a place where kiwi live in the wild :-).

It's a short ferry ride from the city --- about 30 minutes --- but the ferry doesn't run most of the year; after this weekend it won't run again until December. (I've been to Motuihe lots of times but in the past, always on my parents' boat.) The weather today wasn't as good as forecast --- very windy, lots of cloud, and a spot of rain. Nevertheless I think we all had a good time. We walked around almost the whole island in a few hours, having a picnic lunch along the way at one of the smaller beaches (Calypso Bay). Then we walked on Ocean Beach a bit --- a very pleasant beach, generally, although today it was a bit wild with the wind blowing in hard. A few of us went for a swim, which was surprisingly fun, since the water was warm and the waves made it interesting. Auckland has also been experiencing a sequence of very high tides and the high tide today was no exception, which made it fun for the kids swinging on rope swings over the water.

Definitely worth doing if you're an Aucklander and haven't been there before. You can camp overnight on the island, and it's interesting to learn about the history of the island (which includes quarantine station and WW1 POW camp, which hosted the famous Count Felix von Luckner --- a most extraordinary man.)

Thursday, 6 February 2014

Camels

The NZ Herald published a story (reprinted from the Daily Mail) about lack of evidence for camel domestication in the pre-1000BC Levant casting doubt on Biblical references to Abraham and his family using camels before that time. The report seems a bit off to me for a couple of reasons... Contrary to the implication of the article, this isn't by any means a new issue. People have been arguing about this precise question for over fifty years, albeit with a little less archeological data. (See this for example.) Secondly, the obvious rejoinder is that Abraham wasn't actually from the Levant; according to the Biblical narrative he was from Mesopotamia --- where camels appear to have been domesticated much earlier --- and travelled to what is now Israel, bringing his (considerable) household and possessions with him. It would have made complete sense for him to bring some camels with him for the journey, and for that small herd to be maintained and handed down for at least a few generations.

I admit it's a bit foolish to try to analyze data that's passed through the filters of press release and newspaper publication.