Setting the World on Fire

This isn’t normally something I’d syndicate to planet, but it has a certain relevance to Firefox so I thought I’d make an exception here. Feel free to skip by if you want more of the usual fare.

Those of you that have been within a few meters of my laptop or desk or even delved into my website a little may have noticed that I a certain fondness for fractal images. I find them to be extremely beautiful and I’m constantly amazed at what you can generate with what is essentially some numbers and mathematical equations. I’m even more amazed that I can actually generate pieces that look pretty good (IMHO) myself so I’m always happy when others tell me that they like my work. This happened a short time ago when I was asked to create some new art work for Mozilla’s Mountain View office. Apparently my work was selected by the architect and others out of a selection of examples from me and some professional artists.

This was exciting, a chance to get my work on display and up in front of a bunch of people who I love working with no less. I had a pretty good idea of what I wanted the image to look like, not too original I know but a different take on a classic. Just one problem, the sorts of fractal that I am most enamored with of late are called flame fractals and they really aren’t good for designing. You don’t so much decide what you want and just make it. I tend to end up looking through tens if not hundreds of randomly generated images, choosing one that is pleasing and then tweaking it to improve it in my eyes.

In this case I was super lucky, or maybe it was fate. I think I only pored over a few hundred samples until I had the two basic starting points I needed to eventually create this:

This is the first flame fractal I’ve made that is a combination of two separate images which means it takes twice as long to render. The link above is to the low quality version on Flickr but I’ve just finished rendering the full version that will go off to be printed 4ft high on canvas. Thankfully I managed to use my powerful deskop core i7 machine in the office so it only took just under 2 days to render both images at full size. In keeping with the Mozilla spirit I am releasing the fractal definition files and high-res copies of the full image and the individual parts under a Creative Commons Attribution-ShareAlike 3.0 Unported License. Be warned, some of these images are quite large. I recommend right clicking and saving them rather than trying to view them in your browser. You may even need to take care with some image viewers. Trying to use OSX’s quick look feature on them pretty much killed my machine for 20 minutes.

If you want to play around with the image and tweak the settings then I recommend Apophysis for Windows or Oxidizer for Mac. Personally I tend to tweak the images until I’m happy in the GUI editors and then use the command line flam3 tool to do the rendering, binaries are available for Windows from the website and for OSX in macports.

Mossop Status Update: 2010-06-25

Done:

  • Shepherded the Firefox Feedback extension into the tree
  • Reviewed the bulk of the component registration changes
  • Got add-on install success and failure events wired up to the new doorhanger notifications

Next:

  • Still need to triage bugs for beta 2, plan to be API frozen on the add-ons manager by then
  • Finish reviews for component registration
  • Review the upcoming patch for making InstallTrigger support e10s
  • Agree on final mockups for in-content UI

Multiple breaking changes are coming for components in extensions

Are you an extension or application developer? Have you written any XPCOM components, JS, binary or otherwise? If not you can probably ignore the rest of this post, unless you are interested anyway.

If you do then you might be interested to hear that your components are probably going to break in an upcoming Firefox nightly, maybe as early as next week. I’m going to blog specific examples on the changes you need to make once we have better documentation up and builds to test against, for now it is just important for you to know that the changes are coming.

Changing XPCOM component registration

One of the things we are doing is changing how XPCOM components are registered. Previously during registration we would load all binary and JS component files and call them asking them to register themselves. If you used XPCOMUtils.jsm then some of that ugliness will have been hidden from you. The future though will be registration using manifest files, similar to how chrome is registered (in the same files in fact). Every single JS or binary component will need fixes to support this. The amount of work to do is fairly trivial per component and it is possible to support both old and new styles of registration in the same component but until that work is done your components will not work.

Starting extension components later

Currently there are a bunch of different notifications that components can listen for to perform actions during startup. Commonly xpcom-startup, app-startup and profile-after-change have been the most common. The latter is generally the best to use since this is one of the earliest notifications that occurs after the profile folder (and hence preferences and other services) is available.

The news is that once we make our changes components from extensions will no longer be able to register for and receive the xpcom-startup or app-startup notifications at all. profile-after-change will be the first notification that components can be loaded by.

Most of the reasons for loading on app-startup were either because developers didn’t know about profile-after-change or at one point it used to be necessary to load for app-startup just to be able to register for profile-after-change in the observer service. That is no longer the case as you can register for it in the category manager exactly as you can for app-startup.

Why?

You might well ask why we are making all these changes.

Currently whenever we detect a potential change in the set of usable components (meaning either the application version has changed or an extension has been added/removed/enabled/disabled) we must throw away existing component registrations and then perform what has become known as the EM restart where the application is restarted during its startup (in theory invisibly to the user) to make sure that any component that weren’t meant to be loaded are unloaded and to re-register everything and load any new components that need it.

Registration is itself a costly process since every component must be loaded and executed when really many if not most of them do not need to be loaded during startup. In the E10S world there are even more problems. Content processes must either register all components during every startup or somehow share a component cache with the chrome process.

The new registration model allows us to do away with the EM restart. On startup rather than relying on a potentially stale component cache we will read the registrations for the main application out of a manifest file. This will give us enough of XPCOM to then be able to load the extension manager and do any necessary work to install/uninstall/update any extensions after which we can simply load the component registrations for those out of the manifest file. Startup then just proceeds as normal, no restart is necessary since nothing from extensions can have been loaded when it shouldn’t.

E10S content processes can just read the component registrations during startup, since they are in simple manifest files this will go a lot faster

Documenting the new Add-ons Manager

I’ve spent some time this week transferring all the API documentation for the new add-ons manager from the Mozilla wiki to the Mozilla Developer Network. This should now be the place to go for the definitive info.

Right now it is pretty dry, for the most part just pure API info with no examples. Before I started working more on that side of things I wanted to ask what kind of examples people might like to see documented?