Rogue Diplomacy
This weekend I had the opportunity to give a talk about the Mozilla community to a pretty diverse audience. The focus of the event was on open/participatory models of cooperation, so I tried to tilt the talk in that direction. The response was pretty amazing. Despite having only one or two programmers in the audience, there was a ton of engagement, with lots of questions and discussion. I’d originally slated the talk to last about an hour, but it ended up taking 2 and a half hours with all of the audience participation. A lot was discussed about whether the “Mozilla Model” could be applied to other aspects of society, or whether the forkability and patchability of code (that is to say, the ease of experimenting with mutually exclusive solutions simultaneously) makes software a special case. In the end I think that everybody, including myself, learned a lot.
Note to self – don’t recommend Adblock when there might be web publishers in the audience.
I put together some slides (pdf, keynote) for the occasion that I based on Mike Beltzner’s 2009 intern brownbag slides (keynote). I was pretty happy with how they came out, and I’d encourage anyone interested in talking about Mozilla (including beltzner!) to make use of them.
Filed under: Uncategorized | 3 Comments
All Hail QCMS!
Sometime in early 2009, it became clear that lcms as a module wasn’t really working out for us, and we needed to write our own color management implementation (mostly) from scratch. Since I was a full-time student at the time, I didn’t have it in me to lead the effort and get things done in time for 3.5. Thankfully, Jeff Muizelaar stepped in and took up the task, resulting in qcms. I’d encourage everyone to go check out his post.
Also, worry not – most of the work I did on lcms (mainly the performance optimizations) are still there in qcms, so things should be as fast as ever, or faster.
Filed under: Uncategorized | 4 Comments
Checking code into mozilla-central is a serious time commitment. Among other things, the person pushing the patch must watch the Tinderbox for several hours after committing to make sure that no unforeseen problems show up. This is enough of a pain that many of Mozilla’s most senior developers prefer to let other people push patches on their behalf.
It’s much easier to land a patch after hours, since there are fewer other people landing at the same time and so you’re less likely to get caught in someone else’s mess. However, I don’t always want to spend my evenings refreshing the tinderbox page. As such, I’ve always dreamed of having a convenient notification system that I could configure to send me an SMS message when the tree changed status. This would mean that I’d only need to be near a computer, rather than sitting at one, while I was watching the tree.
This evening I was talking to Wolf on IRC and had the idea of piggy-backing on firebot’s tree notification system. Currently, firebot sits on #developers, checking the tree periodically, and speaks up any time the tree changes status. However, there was still quite a ways to go from the IRC channel to my cell phone. I use Colloquy as my IRC client, which has nice support for the Growl notification framework (all Mac only, sorry). Growl, in turn, has a notification option called “MailMe”, which uses your default Mail.app account to send a notification to the address of your choice. Finally, my cellular provider (AT&T) provides a service by which you can email [phone number] AT txt.att.net, and the message will be delivered to that number. So by putting a Colloquy watch-word on “Success”, “Failed”, and “Burning” and setting the Growl notification event JVChatMentioned to use the MailMe plugin, I had firebot sending me text messages. (Side note – Growl does in fact have an SMS plugin, but it requires having an account with a commercial service and seems to cost money.)
The MailMe plugin has a slight problem though: it appends a long footer string to every message. This is fine over email, but it caused all my SMS notifications to span multiple messages, which can get pretty expensive if all the boxes start burning at once. Furthermore, this message was hard-coded into the binary, so there was no easy configuration file to modify. As a result, I grabbed the source, hacked it to silence both the footer and the subject, and made a replacement plugin that you can download here. Just delete the existing MailMe.growlView in /Library/PreferencePanes/Growl.prefPane/Contents/Resources/GrowlHelperApp.app/Contents/PlugIns, drop this one in instead, and you should be good to go. I’m not sure how portable it is, but I can’t imagine any problems if you’re using up-to-date versions of Leapord and Growl.
If you decide to give this a try, let me know how it works out.
Edit: It looks like I forgot to include the source of the (minor) modifications to Growl. I’ve since deleted the directory I was working in, so I just re-did the changes as I remember them and posted them here. I haven’t tested the new patch beyond compilation, but it’s trivial enough that I didn’t feel like it.
Filed under: Uncategorized | 3 Comments
So Many Colors
This summer, I’ve been working on getting Mozilla’s color management backend ready for the prime time. We’re finally turning it on in tonight’s nightly builds, so I thought I’d give a bit of background on the history of color management in Mozilla and on color management in general. You should all go download the latest nightly when it comes out and give it a try.
In a nutshell, color management involves using information about a computer’s display, and in some cases information about certain images, to render pages more accurately. Contrary to popular belief, an RGB value (such as #ffffff) alone does not represent a color. Rather, the values for the red, green, and blue channels can be thought of as coordinates in a color space that contains the actual colors. The color that an RGB tuple represents thus depends on how the color space is defined (see Wikipedia for more information).
This type information is generally stored in a file called an ICC color profile. Computer displays often ship with ICC profiles that specify exactly how various RGB values will look on the screen. Additionally, JPG and PNG images are often tagged with ICC profiles to describe the color space of the pixels. In theory, every image should come with a color profile specifying its color space. However, many images do not contain embedded profiles, nor would it make sense for a CSS stylesheet to embed a color profile for CSS colors. As a result, the W3C determined that untagged web content should be assumed to be in a standard color space called sRGB. So color management in Mozilla is really a two-part process: we map incoming RGB values out of their respective color spaces, and into the color space of your display (which we obtain by querying the operating system).
Colors are more complicated than you might think.
About a year ago, Mike Beltzner unveiled Mozilla’s color management support in a blog post. Unfortunately, there were some major issues that kept the color management mode set squarely to ‘off’ for the release of Firefox 3.0.
First of all, there were quite a few rendering bugs filed for our color management implementation. I was able to confirm a good number of them, and discover a few more myself, and I’ve landed the necessary fixes. There were also quite a few issues with our Reftest rendering test suite that needed fixing so that the tests would pass with color management on. These issues have also been fixed. However, several people reported bizarre rendering behavior (whites showing up yellowish, blues showing up purple) that turned out to be the result of bogus display profiles on the reporter’s system (many thanks to Chris Murphy for lending his expertise on this issue). This is scary, because it raises the possibility that any number of people might see inexplicably weird colors in their browser once we turn on color management. As such, we’re hoping to get as many testers as possible in the nightlies and betas to see how widespread the problem is.
Another concern we had over color management had to do with plugins. Since plugins like Flash and Java do their own drawing, we don’t have any control over whether they use color management. While an extension to the plugin API to allow this is in the works, there’s currently no way for the browser and plugins to coordinate on color management. If the browser color corrects a color while the plugin doesn’t, they no longer look exactly the same side by side. At this point, it’s unclear exactly how much of a problem this is, but we’d appreciate feedback.
However, the biggest reason color management was disabled for Firefox 3.0 was that it regressed performance by about 20-30% (according to our Talos tests) when switched on. This was deemed unacceptable for a default setting. As such, I spent a great deal of time profiling code and then devising, implementing, and testing dozens of strategies to squeeze the performance overhead as close to zero as possible.
This turned out to be really hard. Color management is a per-pixel transform, meaning that we need to call a function for every pixel of an image (CSS colors are easier since repeated pixels are known to the rendering code). Such an embarrassingly parallel problem would be a perfect candidate for GPU acceleration, but we’re just beginning to draw up plans for OpenGL and Direct3D backends to Cairo, so it will be quite a while before we can just write a custom shader and make the entire problem disappear. As a result, I dug in my heels and worked on making the transformation of one pixel really, really fast. After some rearchitecting, various precaching strategies, and a whole lot of hand-tuned SSE2 assembly, the performance overhead of full-page color management is finally at about 4-5% on all platforms.
For the past few months, this seemed to be enough. Beltzner was receptive to the idea of turning it on, and nobody in either of the development meetings raised any gripes on the issue. Robert O’Callahan and David Baron had voiced some concerns about standards compliance and interoperability, but both were willing to turn it on for Firefox 3.1 Beta 1 in order to get feedback from the community. However, as Vlad and I were landing the final patch to turn color management on, we were beset by a flurry of naysayers who didn’t feel like the performance hit was worth it.
As a contingency, I had previously implemented a third mode for color management, one that color-corrects tagged images only, that has a performance hit of about 1%. Safari has been color-correcting tagged images for a while now, and this is certainly the dominant use case for color management. Given the pushback on full color management, it looks like we’ll have to settle for a default of “tagged only” for now. The capability for full correction is available in Firefox, and hopefully we’ll have an easy way to switch modes by the time 3.1 rolls out the door. For now, you can go to about:config and set gfx.color_management.mode to ‘0′ for no color management, ‘1′ for full color management, and ‘2′ (the default) for tagged-only correction (for technical reasons, you’ll need to restart your browser for this setting to take effect). Deb Richardson put together a great blog post where she highlighted some of the differences between color-managing and not color-managing tagged images. I’d encourage you to check it out.
Color Management Off, Color Management On (Courtesy of Deb)
Personal disappointment aside, I think it would be a good idea to open up discussion on the subject of full color management on the web. In a world where every browser supported color management and nobody had bogus display profiles (idealistic, I know), a web designer could pick a color scheme for his or her web page and rest assured that it would actually look the same for each viewer. Whites would really be white, and that soothing hue of green would look just as good on your mother’s laptop as it does on your desktop. I’d encourage people to try browsing the web with gfx.color_management.mode=1. Is the performance impact noticeable? Do you run across any web pages that don’t look right? How many color-matched plugins do you see on a daily basis? Do you care about color correction? As always, Firefox is your browser, and we want to know what you want. So tell us.
Filed under: Mozilla | 62 Comments
Search
