Thursday, 18 December 2014

Queen Charlotte Track

From Sunday to Wednesday I was walking the Queen Charlotte Track with family in the Marlborough Sounds. The weather was excellent; the whole trip was wonderful.

It's a 71km walk and we did it in four days. We flew from Auckland to Blenheim on Saturday and stayed in Picton on Saturday night. On Sunday morning we took a Cougar Line boat to the start of the track at Ship Cove (where Captain Cook careened and resupplied his ships on five separate occasions), then spent five hours walking to "The Woolshed", homestay-ish accommodation at the head of Endeavour Inlet. Remarkably, though the lodges and homes around the Endeavour Inlet are far from any road, they have mains electricity and broadband Internet connectivity good enough to stream video.

The next day we walked three-and-a-half hours to stay at Punga Cove Resort, arriving before 11:30am. Since we had so much time left in the day I decided to try a solo side trip from the resort (sea level) to the summit of Mt Stokes --- at 1200m, the highest point in the Sounds region. I didn't really know what I was letting myself in for; Mt Stokes was nearly 7 hours return from the resort, and a tough uphill slog for much of that, so I was quite exhausted when I finally got back to Punga Cove around 6:15pm. However it was definitely worth it for the amazing views.

Tuesday was the toughest day for the rest of our group, as we walked for about eight hours from Punga Cove along ridges all the way to Portage, staying at Debrett's Backpackers. It's just a long day of up-and-down. We had a decent rest at Black Rock Shelter, which has magnificent views over the Sounds to Picton with snow-capped mountains in the far distance.

Wednesday, yesterday, we did another six hours to reach the trail end at Anikawa around 2:45pm.

The places we stayed were each quite different in character, but all very good. We ate out every night (at Furneaux Lodge, at Punga Cove Resort, and at the Portage Hotel); all the meals were expensive but all also very tasty. We didn't have to carry sleeping bags or cooking gear; we could have made the walk even easier by using the boat service to ferry our overnight bags from one location to the next, but didn't.

This is a really lovely walk and was a great way to experience the Marlborough Sounds. The Sounds are beautiful --- lots of ocean, coastline, hills and islands almost entirely covered with different kinds of native forest. The track is in excellent condition, long but not difficult. You constantly feel compelled to stop and take a photograph of the dazzling view. A remarkable place; a great trip.

Friday, 12 December 2014

rr 3.0 Released With x86-64 Support

I just pushed the release of rr 3.0. The big milestone for this release is that x86-64 support is fully functional! On 64-bit machines, we build a 64-bit rr that can record and replay 64-bit processes with the same set of features and performance-enhancing tricks that we developed for 32-bit. Not only that, but 64-bit rr can also record and replay 32-bit processes or even a mix of 32-bit and 64-bit processes in the same process tree. 64-bit support is mostly due to Nathan Froyd and we hope it significantly lowers barriers to using rr.

Many other internal improvements and sundry bug fixes have landed since 2.0. Some highlights:

  • rr can record executables that use a #! interpreter, e.g. bash scripts. Naturally the entire process tree is recorded, so this simplifies debugging of applications that use complex wrapper scripts.
  • A new rr ps command lists the processes recorded in an rr trace, making it easier to select the process you want to debug.
  • To make that even easier, rr replay -p <command> automatically attaches to the first exec of <command>. E.g. to debug e10s Firefox's first content process, use rr replay -p plugin-container.
  • Sometimes you record a trace, then modify the program but later want to replay the original trace, which requires the original program binaries. rr now uses hardlinks to save files in the trace so that in many cases, old traces are still replayable after a rebuild. Thanks to Karl Tomlinson for the idea.
  • Some small changes in command-line syntax were made to regularize the syntax and prepare for future expansion.
  • Many bug fixes to broaden the range of recordable applications. E.g. LibreOffice and QEMU work now.

Development carries on; visit rr-dev for exciting updates.

Have fun using rr!

Monday, 8 December 2014

Portland

Portland was one of the best Mozilla events I've ever attended --- possibly the very best. I say this despite the fact I had a cough the whole week (starting before I arrived), I had inadequate amounts of poor sleep, my social skills for large-group settings are meagre, and I fled the party when the music started.

I feel great about Portland because I spent almost all of each workday talking to people and almost every discussion felt productive. In most work weeks I run out of interesting things to talk about and fall back to the laptop, and/or we have lengthy frustrating discussions where we can't solve a problem or can't reach an agreement, but that didn't really happen this time. Some of my conversations had disagreements, but either we had a constructive and efficient exchange of views or we actually reached consensus.

A good example of the latter is a discussion I led about the future of painting in Gecko, in which I outlined a nebulous plan to fix the issues we currently have in painting and layer construction on the layout side. Bas brought up ideas about GPU-based painting which at first didn't seem to fit well with my plans, but later we were able to sketch a combined design that satisfies everything. I learned a lot in the process.

Another discussion where I learned a lot was with Jason about using rr for record-and-replay JS debugging. Before last week I wasn't sure if it was feasible, but after brainstorming with Jason I think we've figured out how to do it in a straightforward (but clever) way.

Portland also reemphasized to me just how excellent are the people in the Platform team, and other teams too. Just wandering around randomly, I'd almost immediately run into someone I think is amazing. We are outnumbered, but I find it hard to believe that anyone outguns us per capita.

There were lots of great events and people that I missed and wish I hadn't (sorry Doug!), but I feel I made good use of the time so I have few regrets. For the same reason I wasn't bothered by the scheduling chaos. I hear some people felt sad that they missed out on activities, but as often in life, it's a mistake to focus on what you didn't do.

During the week I reflected on my role in the project, finding the right ways to use the power I have, and getting older. I plan to blog about those a bit.

I played board games every night, mostly Bang! and Catan. It was great fun but I probably should cut back a bit next time. Then again, for me it was a more effective way to meet interesting strangers than the organized mixer party event we had.

We Aren't Really Going To Have "Firefox On iOS"

Whatever we decide to do, we won't be porting Firefox as we know it to iOS, unless Apple makes major changes to their App Store policies. The principal issue is that on iOS, the only software Apple allows to download content from the Internet and execute it is their built-in iOS Webkit component. Under that policy, every browser --- including iOS Chrome, for example --- must be some kind of front-end to Apple's Webkit. Thus, from the point of view of Web authors --- and users encountering Web compatibility issues --- all iOS browsers behave like Safari, even when they are named after other browsers. There is some ability to extend the Webkit component but in most areas, engine performance and features are restricted to whatever Safari has.

I certainly support having a product on iOS and I don't necessarily object to calling it Firefox as long as we're very clear in our messaging. To some extent users and Web developers have already acclimatised to a similar confusing situation with iOS Chrome. It's not exactly the same situation: the difference between iOS Chrome and real Chrome is smaller than the difference between iOS Firefox and real Firefox because Blink shares heritage and still much code with Webkit. But both differences are rapidly growing since there's a ton of new Web features that Chrome and Firefox have that Webkit doesn't (e.g. WebRTC, Web Components, ES6 features, Web Animations).

In the meantime I think we need to avoid making pithy statements like "we're bringing Firefox to iOS".

Thursday, 27 November 2014

The Rise Of "Versing"

My children frequently use the word "verse" as a verb --- not in the technically correct sense of "to compose verses", but as a transitive verb form of the preposition "versus". For example they might say "I'll verse you at Monopoly." For a long time I'd never heard this usage other than from my children (though I assume they picked it up at school), but recently I saw it in a New Zealand online forum. I wonder if this originated locally and whether it will stick. I think it's actually a useful word; the closest equivalent I can think of is "play", but in my mind "I'll play you at Monopoly" doesn't carry the same emphasis on competition.

Saturday, 22 November 2014

Mount Te Aroha

Today we drove to the town of Te Aroha and walked to the summit of Mount Te Aroha. It's about a 1 hour and 40 minute drive from Auckland to the town, which is at the foothills of the Kaimai Range south of the Coromandel Peninsula. It's a beautiful small town surrounded by the green fields of the Hauraki Plains and backed by the magnificent forested Kaimai mountains.

It takes us about two hours to walk from the town to the summit of Mount Te Aroha --- a steep (900m elevation change) but very pleasant walk through forest with periodic views over the countryside. The summit is quite exposed, and has been windy and cold both times I've been there, but the views (when not enveloped in cloud cover) are magnificent. To the north you can see the Firth of Thames and the Hunua Ranges (beyond which lies Auckland; the other side of the Hunuas is visible from my desk in the Mozilla office). To the west are the verdant Hauraki Plains and the green hills of the Waikato. To the south the Kaimai Range stretches into the distance in an impressive line. I've read that on a clear day you can see Mount Ruapehu to the southwest, but I haven't yet. To the east you can see the eastern side of the Kaimais and the Coromandel Peninsula, and the Pacific Ocean beyond --- with Mayor Island and Matakana Island (near Tauranga). It's wonderful, and well worth the trip.

Friday, 14 November 2014

Relax, Scaling User Interfaces By Non-Integer Scale Factors Is Okay

About seven years ago we implemented "full zoom" in Firefox 3. An old blog post gives some technical background to the architectural changes enabling that feature. When we first implemented it, I expected non-integer scale factors would never work as well as scaling by integer multiples. Apple apparently thinks the same, since (I have been told) on Mac and iOS, application rendering is always to a buffer whose size is an integer multiple of the "logical window size". GNOME developers apparently also agree since their org.gnome.desktop.interface scaling-factor setting only accepts integers. Note that here I'm conflating user-initiated "full zoom" with application-initiated "high-DPI rendering"; technically, they're the same problem.

Several years of experience shows I was wrong, at least for the Web. Non-integer scale factors work just as well as integer scale factors. For implementation reasons we restrict scale factors to 60/N for positive integers N, but in practice this gives you a good range of useful values. There are some subtleties to implementing scaling well, some of which are Web/CSS specific.

For example, normally we snap absolute scaled logical coordinates to screen pixels at rendering time, to ensure rounding error does not accumulate; if the distance between two logical points is N logical units, then the distance between the rendered points stays within one screen pixel of the ideal distance S*N (where S is the scale factor). The downside is that a visual distance of N logical units may be rendered in some places as ceil(S*N) screen pixels and elsewhere as floor(S*N) pixels. Such inconsistency usually doesn't matter much but for CSS borders (and usually not other CSS drawing!), such inconsistent widths are jarring. So for CSS borders (and only CSS borders!) we round each border width to screen pixels at layout time, ensuring borders with the same logical width always get the same screen pixel width.

I'm willing to declare victory in this area. Bug reports about unsatisfactory scaling of Web page layouts are very rare and aren't specific to non-integral scale factors. Image scaling remains hard; the performance vs quality tradeoffs are difficult --- but integral scale factors are no easier to handle than non-integral.

It may be that non-Web contexts are somehow more inimical to non-integral scaling, though I can't think why that would be.