Firefox Invalidation

As promised, I’m going to call out Firefox Layout & Rendering code changes that my team has been working on. This bug fix from Bas Schouten (as reviewed by Robert O’Callahan) was one of those light-bulb code changes that have really advanced my understanding of the Gecko Layout Engine’s graphics code:

This check-in implements “Paint Flashing”, a diagnostic tool that shows when the browser is invalidating (or repainting) a screen region that has changed. It’s very useful for diagnosing redundant (painting too often) or greedy (painting too large an area) invalidation. Both kinds of bugs are notoriously hard to find.

Paint Flashing will paint a random color (at 20% opacity) to indicate the “damaged” area of the screen that the browser is repainting. You can enable Paint Flashing by setting this preference to true:


If you’re running a DEBUG build, you can get to it in the Layout Debugger. The code is deceptively simple but shows the logical bottleneck where invalidation occurs in Firefox. We’re already using this tool as we evaluate larger invalidation changes that aim to dramatically speed up rendering in Firefox. You can also use this tool as you develop your web apps to see if performance issues are the result of invalidation problems. You can tune your app much better if you know how much screen area is getting painted from your javascript or CSS code.

Flash: I’m not dead yet!

My last post generated a fair bit of discussion around the true fate of Flash within Adobe. The original announcement from Adobe and the associated staff reductions had caused a lot of speculation within the Flash community. I should clarify some of my statements, especially the parts about the Flash Pro authoring tool and Flash Player.

All software follows a similar life cycle from 1.0 to a final version when it effectively becomes frozen in time. I didn’t mean to imply that Adobe is pulling Flash Pro from store shelves like salmonella-tainted spinach. A familiar pattern is to move software engineering to a low-cost geography like India or China as growth slows. This is not a bad thing, and actually lets the software have a long tail of maintenance and incremental feature work at a cost that allows it. The consumer can still count on that software being available for some time with support (usually from the same low-cost geography.) A handful of engineers will remain in the original geography to consult the new engineers as the hand-off occurs. The Flash Pro team in the US will have a handful of engineers left behind to manage the hand-off so, technically, the entire team is not getting eliminated at this time. Over time, the idea is to have your higher-cost engineers migrate over to your higher-growth projects. This is what occurred many years ago at Macromedia when Director moved offshore and the team moved over to working on Flash.

Last Tuesday’s announcements did not follow this pattern. Instead of moving the mobile Flash Player to a low-cost geography, it was discontinued outright. Instead of moving many affected Flash Platform engineers to the next high-growth agenda, they’re getting sent home. These events are what prompted me to write my last post as my friends at Adobe were blindsided by the whole affair.

I have a great deal of respect for the Adobe product managers who are trying to contain the damage and reverse the Elop Effect from the original announcement. It does seem like they were not made aware of the Tuesday announcement in advance. I sincerely hope they will be successful at affecting change within Adobe to keep Flash around for a good while longer.

Did Adobe finally kill Macromedia Flash?

Adobe announced that it is ceasing development on the Flash Player for Mobile Devices. As you may know, I was on the engineering team that brought Flash Player 10.1 to Mobile Devices back in June, 2010. This announcement is disappointing for many reasons, but not surprising given the realities of mobile web development.

While I was at Adobe, we spent a great deal of time and energy to get the Flash Player to run fast enough on the HTC Nexus One running the Android OS. At the same time, Apple was making it very clear that Flash would never be allowed to run under Mobile Safari, especially if our goal was to have it work on Android first. The writing was already on the wall even before we shipped: no matter what we did, or how well we did it, we were not going to have our ubiquitous platform extend to the Mobile world.

Of course, that’s not the whole story. What I’m truly disappointed about is that Adobe is exiting the Flash Platform business–they laid off 750 people yesterday, including the entire US-based Flash authoring tool team. This means that offering a free Flash Player runtime subsidized by selling tools is no longer a business Adobe is interested in. I always worked to ensure that SWF as a data type could have the same ubiquity as JPEG. That is, you could trust that the SWF you authored in 1998 would be rendered by a publicly available runtime in 2028. For this to happen, you need to have an organization that can shepherd the technology and commit to doing so for all time.

Unfortunately, Adobe is not that organization.

Or is it? I hope that they release the runtime code to the public domain so that others can extend and maintain it. I’m well aware that there are 3rd-party licenses in the code, but that can be easily redacted. If there is any hope left for Flash to survive, it will have to be an open-source implementation that can fulfill the promise of a ubiquitous rich-media data type for years to come. Adobe needs to acknowledge that the public needs SWF to survive, and that opening up the platform is now the only way to ensure that outcome.

Mozilla Festival, London UK

I will be in London from November 4-6 to take part in the Mozilla Festival. The festival will be at the Ravensbourne College in Greenwich (in the beginning of time—GMT.)

The organizers are actively looking for more developers and designers to add rocket fuel for the Festival’s roster of design challenges and hack sprints. More specifically, they are looking for more:

  • Javascript developers, HTML5 video and audio enthusiasts, front-end developers, news app developers, and other news hackers, to help build everything from data-driven journalism kits to mobile news apps to amazing browser-based video games that run right in the browser.
  • User experience and interface designers, graphic designers, game developers, and 3D modeling people, to help create everything from data visualizations to translation workflow to whole new ways of imagining news and information.

Know anyone who fits the bill? Please ask them to join us in London by signing up here:

If you have people in mind who would be perfect but could have a tough time paying the event fee, please send me a note. We’ll find a way to get them in.

Graphics Engines in Firefox

One of the key goals for the Firefox Layout & Rendering team is to improve performance for web applications. Web apps nowadays push the graphics rendering stack in ways that rival console games. To that end, our existing rasterizer was hitting its limits in terms of the sheer volume of data we now push through it on a a regular basis. Switching out a shipping application’s raster engine is a big deal that requires a lot of scaffolding. When I was working on the Flash Player, I saw how much work goes into integrating a new graphics engine into a shipping product. Sometimes, you have no choice but to tack it on top of (or in Flash’s case, behind) the existing rasterizer.

For Firefox, the scaffolding involves the addition of the new rasterizer initially for the  <canvas> API’s. This was ideal because it was fairly localized, and backwards-breakage risk was manageable. In the next phase, all CSS layout styling will use the new engine. The lessons learned from <canvas> make this a much less risky phase but it’s still fraught with peril. The benefits will be worth it, especially when we get page-draw and responsiveness metrics cranked up.

I’ll be posting up more details on Layout & Rendering internals as I dive deeper into it. It’s quite exciting to work on the guts of the Web with passionate engineers.

Shipping already? I just got here!

Firefox 7.0 shipped today. While I can’t take any credit for any of it, my team deserves all the praise. They’ve been hard at work on reducing memory all over the product. I’ve had a few people complain to me about “pork” in Firefox and we’re making some big changes to cut the fat. It’s interesting how getting a new job just means new complaints from the same cadre of “stakeholders.” Let me know via the blog comments if Firefox is working better (or not) with all these optimizations.

Interviewing in Silicon Valley

I spent a fair amount of time interviewing for jobs before landing the one I have now. Sitting in the interviewee chair was a learning experience after many years at the same company—it had been a long time since I was an external candidate. This post might help others sitting on either side of a Silicon Valley interview.

I’m a Software Developer who manages other Software Developers. This is an important point because I was interviewing for management and non-management roles at the companies I visited. I wanted to lead a team with a strong engineering foundation. From my experience, effective teams inevitably grow to require new leaders and I would much rather be an engineer on a strong team that will grow to need (me as) a leader than to come in to lead a weak team. I also wanted to learn how a company hires its engineers as it is a good indicator of their other business practices.

There’s plenty of evidence that a manager can have an unfairly significant influence on a team or company’s culture. Hiring managers should therefore take more time and care than hiring an engineer, but what are the differences in interviewing for either case? Management style is a key indicator of culture fit, which can be the difference between success and disaster. Good interviewers asked questions that invite dialog:

  • Did you ever fire anyone? Why/how?
  • How do you find/manage poor performers?
  • Tell me a success story and a horror story at your last job. (Very telling, but allow enough time for both stories.)
  • Describe your management style.

In general, the non-technical questions were a good way to learn about a candidates cultural leanings, but were not necessarily a good way to tell if they’re any good at making software. A few interviewers fell into the trap of using the wrong technical questions to determine fitness for this purpose. There was a wide disparity in the quality of technical questions used at interviews. By quality, I mean the effectiveness of a given technical question in determining a candidate’s ability to contribute to your specific software project.

The answers to most technical interview questions can be found on the web. Interviewers need to assume that, if hired, the candidate will have the Internet at work to solve these kinds of problems. For example, any question with “hash table” as a correct answer should be avoided. Questions that have no relevance to real work are just annoying. Don’t ask for code you won’t use. In my many years as a professional developer, I have never seen a need to reverse a text string in a commercial software product.

It’s much more effective to talk about real technical problems with the project that you’re hiring for. A couple of interesting ones I was asked involved real bugs in the actual product. That was cool for me as the interviewee who learned some real-world problems I’ll encounter if hired, and good for the interviewer who may get a free bug fix in the deal. It also got a good dialog going on diagnosis/debugging techniques.

Use caution with coding exercises. It’s important to remember that programmers don’t formulate solutions alike. A whiteboard coding exercise will not be the best way to predict a programmer’s style when a real editor, compiler and debugger are available. What you’re looking for is the presence or absence of key elements in the algorithm–not the syntax. Don’t come with a coding exercise and expect the code on the whiteboard to look exactly like how you’d do it. In one interview, I was asked to implement a 1-bit run-length encoder. Although 1-bit RLE is an awful compression technique for all but the most basic monochrome bitmaps, it tells you if the candidate can understand loops and bit-operations. I’ve posted my code here, effectively reducing this interview question to another one you can answer with a web browser.

Good luck in your search!

New Beginnings!

I recently started working on Firefox. To be more specific, I help run the Gecko Layout Team for the Mozilla Corporation. My team is responsible for everything you can “see” in Firefox. As you can imagine, the team is very busy.

I really enjoy working on software used by hundreds of millions of people. Before I started working on Firefox full-time, I managed Software Engineering for the Adobe Flash Player. Before that, I worked on a bunch of other software used by lots of people. After 13 years at Adobe and Macromedia, it was time for me to make a change.

I started looking for an opportunity that would let me continue working for a global audience and allow growth through new challenges. At Adobe, I had the opportunity to work with all the browser vendors to make sure that the Flash Player worked on their products. I really enjoyed working with the Mozilla people, so I reached out to let them know about my plans. They’re hiring lots of new staff and needed help on Engineering Leadership to scale the organization. After a very rigorous interview process, I started work on September 12, 2011.

In the short time I’ve been at Mozilla, it’s already clear that this place is run by Engineers. I love it! It feels a lot like Macromedia did when I started there in 1998. My first day on the job was at the San Jose Convention Center where the Mozilla employees had their All-Hands meeting. There was far more energy and enthusiasm at the Mozilla All-Hands than at the last event I saw at the Convention Center (which had 10x as many attendees!) Everyone at Mozilla is definitely on a mission and charged up…

  • It’s not enough to not be evil.
  • It’s not enough to be good at what you do.
  • You have to Do Good.