The roads I take...

This has been a long time coming, actually, and recent developments just put the final nail in the coffin.

I am ending all development and support for my "extension"-type add-ons effective immediately.

This affects (daily user numbers according to addons.mozilla.org):

• Jökulsárlón Download Manager (almost 500 daily users, source on hg.m.o)
• KaiRo.at Mandelbrot (roughly 1000 daily users, source on git-public.kairo.at)
• Tahoe Data Manager (slightly over 300 daily users, source on hg.m.o) - this is also a default part of SeaMonkey.

If anyone is interested in taking over development and maintenance of any of those, please let me know and I'm happy to convert their repositories over to github for easier working with them, and and the new developer to their administration on AMO and/or move them over to you completely.

I will leave them listed on AMO for a little while so people who want to take over can take a look, but I will hide them from the site in the near future if nobody is interested.

The reasons for this step are multiple:

For one thing, I just don't have the time for updating their code or improving them. My job is stressful enough that my head is overflowing with Mozilla-related things all the time, and my employer is apparently not willing to give me any relief (in terms of hiring someone to supplement me) that would give me back sanity, so I need to remove some Mozilla- and software-related thing from my non-work time to gain back a little sanity so that I don't burn out.

I am also really sad that apparently nobody finds the time or energy to make decent managing and notification mechanisms available for UI code around the new-style web storage mechanisms like indexedDB, appCache, or ServiceWorkers caching, while we do have quite nice APIs there for long-standing things like cookies. For getting Tahoe Data Manager (which was my most interesting add-on) to work decently, I would have needed decent APIs there as well.

Then, my interest for experimenting with code has moved more and more away from the browser, which keeps changing around me all the time, and towards actual web development, where existing code doesn't get broken all the time and your code is more isolated. As a bonus, I can develop things that run on my (Firefox OS) phone and that I can show other people when I'm somewhere. And even there, I don't get as much time to dig into stuff as I would like to, see above.

And finally, and that's why this culminates right now, I disagree with some pieces of Mozilla's add-on strategies right now, and I don't want to be part of that as an add-on developer.
For one, I think add-on signing is a good idea in principle, but not enabling developers to test their code in any way in the same builds that users get is against everything I learned in terms of quality assurance. Then, requiring developers and other users of unbranded (or early pre-release) builds to turn off security for everything just to use/test one or two unsigned add-ons just feels plainly wrong to me (and don't tell me it can't be done otherwise, as I know there are perfectly good ways to solve this without undermining signing and preserving more safety). And I also fear that, while add-on signing brings a lot of pain to add-on developers and will make us lose some of them and their users, we will not reduce the malware/adware problem in the mid to long term, but rather make it worse, as they will resort to injecting binary DLLs into the Firefox process, which is the primary cause of startup crashes on updates, and I will have more grief in my actual job due to this, next to Firefox losing users that see those crashes.
And on the deprecation of "the permissive add-on model" as they call it in the post, I think that the Firefox UI being written in web (CSS/JS/HTML) or web-like (XUL) technologies and the ability to write add-ons that can use those to do anything in Firefox, including prototyping and inventing new functionality and UI paradigms, is the main thing that sets Firefox apart product-wise from all its competitors. If we take that away, there is no product reason for using Firefox over any other browser, the only reasons will be the philosophy behind Mozilla (which is what I'm signed up for anyhow)and the specific reflection of those in some internals of the browser, like respecting privacy and choice a little bit more than others - but most people consider that details, and it's hard to win them over with those. Don't get me wrong, I think that the WebExtensions API is a great idea (and it would be awesome to standardize some bits of it across browsers), and add-ons being sandboxed by default is long overdue. But we also would need to require less signing and review for add-ons that are confined to the safe APIs provided there, and I think we'd still, with heavy review, signing, and whatnot, need to allow people to go fully into the guts of Firefox, with full permissions, to provide the basis for the really ground-breaking add-ons that set us apart from the rest of the world. Even though almost all of the code of my add-ons ran within their own browser tab, they required a good reach into high-permission areas, which probably the new WebExtensions API will not allow that way. But I also do not even have the time to investigate how I could adapt my add-ons to any of this, so I decided to better pull the plug right now.

So, all in all, I probably have waited too long with this anyhow, mostly because I really like Tahoe Data Manager, but I just can't go on pretending that I will still develop or even maintain those add-ons.

Again, if anyone is interested in taking over, either fully or with a few patches here and there, please contact me and I'll help to make it happen.

(Note that this does not affect my language packs, dictionaries, or themes at this point, I'm continuing to maintain and develop them, at least for now.)

In the last days, I did some JavaScript performance tests on different SeaMonkey versions on my machine, just to find out where we are heading for SeaMonkey 2.1 in comparison to what we shipped in the past:



I ran 3 tests there: my personal Mandelbrot demo 1.0 with default settings (blue), the pretty common SunSpider benchmark (red), and the new Kraken benchmark (yellow). Note that the scale of Kraken results is different to the scale of the other two.

(Update/Note: I was told that my Mandelbrot demo uses JavaScript 1.7 and HTML5 features that Mozilla 1.8 supported but other browsers still don't, so there's a more cross-browser Mandelbrot demo 2.0 now - that one performs even a tad better on Mozilla trunk than the results here.)

The builds I tested were current pre-2.1 trunk builds, which already have the first stage of the new JaegerMonkey JavaScript engine, 2.0 branch builds without and with the venkman JavaScript Debugger add-on enabled (without JSD means that TraceMonkey can fully work, as activating venkman makes JSD put JavaScript into a non-tracing debug mode) - and finally, the 1.1.19 release build.

Unfortunately, I can't get data for Kraken on 1.1.19, as after a very very long time of running (given the "slow JavaScript" warning is deactivated), it errors out with not finding any JSON support. Comparing to the other tests, it suffices to say that SeaMonkey 1.1.x, coming from the Mozilla 1.8 tree, is very slow - but then, that's the baseline we started from.

SeaMonkey 2.0.x - even with venkman on and JSD knocking tracing off - is 90% or more faster than 1.1.x in those tests we can run in the older version. Suffice to say that Mozilla's JS team has made tremendous improvements between the 1.8 and 1.9.1 branches of the platform. One might think it's hard to go even further after such a jump, and indeed it has become much harder - but things could still get better. First, turning the debugger off and tracing on wins 19% in SunSpider, 13% for Mandelbrot and 2% for Kraken (the latter either doesn't have a lot of tight loops, which is what tracing help most with, or we are bad at tracing them in this version). At this level, SeaMonkey 2.0 looks already nice - but that's still 1-2 years old code, and development continued.

The current pre-2.1 builds of SeaMonkey bring another 61% win on Mandelbrot, 66% on SunSpider and 72% on Kraken - over 2.0 with full tracing! While the basic Mandelbrot set image took over 25 seconds to calculate and display on 1.1 and significantly over a second on 2.0, we're under half a second now for pre-2.1 code. And, as I already mentioned, JaegerMonkey work isn't even finished yet, there's a few more things to come there.

Of course, the question is if what those tests run is what Web sites and applications really need - we know a few things in SunSpider are non-realistic workloads. Kraken tries to look into CPU-intense workloads that could be useful for actual web applications, esp. if they want to to things like image and audio processing. My Mandelbrot set demo may look far-fetched, but then, I can surely see websites or even more web games dynamically generating fractal-based shades and textures based on variable parameters, and there you might have very similar code.

For those people who want the hard facts, here's the numbers for my graph with all details:

• Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre SeaMonkey/2.1b1pre
• Mandelbrot: 483.0ms +/- 1.4% (0.481, 0.492, 0.474, 0.487, 0.481)
• SunSpider: 477.4ms +/- 1.1%
• Kraken: 11151.6ms +/- 0.5%

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.13pre) Gecko/20100913 Lightning/1.0b2pre SeaMonkey/2.0.9pre

Mandelbrot: 1421.8ms +/- 5.0% (1.336, 1.401, 1.497, 1.383, 1.492)

SunSpider: 1738.0ms +/- 2.6%

Kraken: 40428.1ms +/- 1.6%

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.13pre) Gecko/20100913 Lightning/1.0b2pre SeaMonkey/2.0.9pre (venkman disabled)

Mandelbrot: 1237.6ms +/- 3.3% (1.220, 1.216, 1.301, 1.197, 1.254)

SunSpider: 1402.2ms +/- 3.6%

Kraken: 39558.9ms +/- 1.5%

Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19

Mandelbrot: 25214.2ms +/- 1.0% (25.176, 24.907, 25.180, 25.216, 25.592)

SunSpider: 17501.2ms +/- 1.2%

Kraken: Runs slowly for a while, but does break for not finding JSON handling.

All in all, the Mozilla JavaScript team is really enabling a lot of new possibilities here, as now we can do things client-side we needed to do server-side up to now, and that makes completely new dynamics possible. And SeaMonkey fully features those improvements made by the Mozilla community.

As I've mentioned here before, I have done some work on recreating the VB app from my high school thesis as a XULRunner application - esp. as I could need the coding practice and Mandelbrot set calculation can nicely show off TraceMonkey's speed.

XULRunner apps are cumbersome when it comes to packaging and delivering them to someone else, though, so I decided to "add-on-ize" this application, and I just finished that and submitted it to AMO. It's even nominated for public, but we'll see how that goes.

So, if you want to try it yourself, you can now get KaiRo.at Mandelbrot for Firefox and SeaMonkey!

In theory, it should even work on mobile Firefox, but I have only tested the XULRunner version on my N810, not the add-on version, and it's not really fit well for the UI. So, it's just experimental, but still nice to show off XUL+JS+canvas+TraceMonkey on a mobile device!


In related news, Data Manager is also available in a first version as an add-on on AMO. This version can now show all the data I want it to display for now, but has rough edges and doesn't let you edit or manage anything yet. Because of this raw state, this will not be "public" for now and versions will stay in beta. Still, I wanted to make it available for testing, so it's there.

Feel free to help testing and get Data Manager for Firefox and SeaMonkey!

NB: I wonder if I should rebrand this to "SeaMonkey Data Manager", just for the fun of Firefox people being able to have the same experience as we have with the Firefox Sync confusion.


With all that, my add-on developer panel on AMO now lists 10 add-ons.

This week, I found some more time to hack around on my fun project to do a Mandelbrot set fractal renderer in XULRunner - some of that fun hackery done on the N810, some on my desktop, finally some on my laptop, and now those sources create a really usable application.
The only thing holding me back from doing a downloadable "(pre)release" package of any kind is that it's still somewhat hard to do that for XUL/JS-only XULRunner apps. I'd need to compile my own XULRunner and package it with that or such to get a usable downloadable thing.



What I added this week to bring it over the top was a zoom function that works by dragging the mouse over any piece of a rendered image and a possibility to bookmark locations and call them up again at a later point. With that, one can easily navigate to different places and get pictures like the one above - my laptop calculated and rendered the original 1280x1024 picture in a matter of seconds, with a 1.9.1 XULRunner from some time this weekend, so the same TraceMonkey present in Firefox 3.5.2 to calculate all those iterations, and I did save the contents of the canvas used to paint it as a PNG with the functionality I have in the application. Any quality degradation comes from scaling and converting to JPEG on my web server.

Oh, and there's one more interesting picture I did get out of this work:


(larger sizes linked, original 1280x1024 desktop-wallpaper-ready version available on personal request)

All the fractal pixels in this image come from TraceMonkey's calculation again, of course, but the GIMP helped slightly to finish off this one.

Yesterday, I held a talk on Linuxwochen Wien, a local Linux and Open Source conference. My talk was right before Brian King took the stage (who talked mostly about the add-on ecosystem), so it fitted well that my topic was "The Open Internet and Mozilla". My slides (in German) are online at kairo.mozdev.org.

I included a number of the HTML5 demos from Paul Rouget to show what open web technologies can do, but for showing the power of JIT, I showed a demo I quickly did myself:
Ripped out of the code for my Mandelbrot XULRunner app, I put up a <canvas> and some JS code up on a website, with a small HTML form for selecting coordinates, etc. - and the Mandelbrot-Web demo was done!

It's not too beautiful, just a fast hack, but running the default image calculation in both Firefox 3.0 and a current 1.9.1-based nightly, I could show how the time needed for calculation (and display in the canvas) dropped from 7.3 to 1.6 seconds on my laptop due to the TraceMonkey JIT engine.
A number of people seemed impressed with both that and the stunning video+canvas demos from Paul.

Finally, I could even announce a whole one-day event on the Open Internet right here in Vienna! As both Mozilla and the local quintessenz association (who also organized Linuxwochen) have agreed to work together in organizing this, I could point people to the MozCamp Wien taking place on October 27, 2009.
We are in the very early stages of planning, not knowing much more than the date, the topic and the format (MozCamp in the way it has been done in Utrecht in March), but stay tuned here for updates on details as we get them figured out!

When I opened the source to my Mandelbrot fun project, I did this because I hoped people would look into what TraceMonkey could optimize better there, and because I hoped an open example application helps others base their apps on XULRunner.

Now the second part is a long-term goal that I don't expect will be something that happens soon, but the first point has already been followed: As Boris points out in his comment, he filed two bugs on TraceMonkey, being able to use my code or variations of it as testcases, and there are good chances TraceMonkey will be improved to speed up those cases as well.

Additionally though, Boris pointed out possible ways to improve my code in an earlier post after reading it, and a guy calling himself "prefiks" implemented those ways and a bit more in a patch linked in another comment. When I applied that patch, the numeric algorithm approach with TraceMonkey enabled was sped up by a factor 5 and now I get the base image painted in 1.2 seconds on my machine - and even see updates of the image during drawing, which is what I wanted all along! I also tested it with the XULRunner of Fennec M7 on my N810, and even though it takes a bit over 90 seconds to paint this image, one can watch it build up and so it even feels usable there!

So, opening the source should help TraceMonkey being improved and even helped me making my fun side project more usable. This is the power of keeping the source open, and I hope an encouragement for other people to do the same.

As comments to yesterday's post about TraceMonkey suggested I should show my code so the JIT code could be improved for things like what I'm doing, I decided to go all the way and publish this today.
I just completed putting all my code of this project under the Mozilla tri-license and making it available via both a gitweb interface and for cloning with git clone http://git-public.kairo.at/mandelbrot.git.

That said, a few details about the application itself:

This is a fun side project, its main target is for me to learn XULRunner and improve my skills with the used technologies. Its second target is to recreate an application I had started for my my final paper in school with modern technologies.
The application renders images of the Mandelbrot set fractal, the original application had nice zoom functionality and could even render the very similarly calculated family of Julia set fractals, which are both features I want to add incrementally to this XULRunner-based version as well.

The current versions calls itself "KaiRo.at Mandelbrot 4pre", which probably warrants a short view on the version history: The first version, "RK-Mandelbrot 1.0" was created in Visual Basic 3 during work on that school paper, I incremented the minor version number as I went along with that work, the version I had on a disk coming with the paper was "RK-Mandelbrot 2.0", this or a slight minor update to it was also used during the presentation/exam on that paper. I later updated it to Visual Basic 5 and played with a few features, calling the result "KaiRo-Mandelbrot 3.0", also noting the change from using my initials to the "KaiRo" name for my work. Because of this history, I'm targeting a version number of 4.0 for the XULRunner rewrite, and also using "KaiRo.at" as the vendor name, as that's also what I'm using as my corporation name prefix.

Some comments on the current code:

On the base level, I created a mandelbrot launch script, which tires to find a XULRunner in a few places and uses it to launch the app using the application.ini inside the xulapp directory, which contains files in the usual structure for XULRunner apps.

In the running app (the launch script also launches the error console for debugging), the File menu enables access to drawing the image, saving it (very ugly right now, hardcoding /home/robert/temp/canvas-save.png as the path!) and quitting the app. The Settings enables different settings for maximum number of iterations (I'm using a simple escape time algorithm) and color palettes (which are currently stretched according to the max iterations number; also, I have not ported all palettes I had in the VB version, leaving the non-ported ones in an ugly comment in the JS file). Today, I also added a Debug menu that allows switching TraceMonkey on and off and switching between the slow but nice-looking object-oriented algorithm and the faster but not so pretty numeric algorithm. I also added a label at the bottom of the window that informs about the currently performed action and a rough time measurement when drawing is complete.

The image you'll get with the default settings of max. 500 iterations and my custom "KaiRo.at" color palette looks like this:

Once I can do a zoom function, I hope I can produce more interesting images - I'll publish a number of them in the gallery.

There's a lot that probably can be improved in that app, it's just a fun personal playground, as I said. But if anyone wants to look into what it does and perhaps see how TraceMonkey could perform better on it, feel free to look into it, the source is all open!

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 33/2008 (August 11 - 17, 2008):

• Vacation Catch-Up:
  I spent a huge amount of time this week catching up on things that happened during my vacation and partly the Mozilla Summit, am done with all my digging through bugmail, newsgroups, planet, pushlogs and most of the normal email and started some real work again.
• Mercurial Move Followup:
  Catching up my the pushlog feeds on the mozilla buildsystem files we've copied in modified ways to comm-central, I ported recent fixes to our versions already, with more under review.
  Additionally, --disable-compile-environment should work now (used in some L10n docs).
• Build/Test Machines:
  I've made a patch that should allow us to have our unit test boxes go green even though we have known leaks. We'll set thresholds to allow the current amounts of leaks without failure so we at least reliably catch when leaks increase. We'll adapt those thresholds values as possible when leaks get fixed, so that we'll hopefully only go down but not up with what we allow.
  We're also working on getting Justin Wood (Callek on IRC) access to our build machines, so that he can act as a backup when I'm not around (like recently, when they broke while I was on vacation).
• Bugzilla's SeaMonkey Product:
  Now that the big bugzilla.mozilla.org reorganization has been done and we have a product named "SeaMonkey", we still need to see that component info gets updated and missing components are created.
  Also, we have new bug triage targets and would like people to participate in killing off and/or improving our bug reports!
• xpfe Cleanup:
  With the new situation of only toolkit applications being based on trunk, I started work on cleaning up xpfe/ again, the first patch removes all but one file of xpfe/global and xpfe/communicator from mozilla-central.
• German L10n:
  I worked on resyching the German hg repo with hg trunk code together with my de team colleagues, along with fixing linebreak error made obvious by the new MozillaTranslator version and a typo.
  Also, I could verify that the existing Makefile targets produce working German langpacks and tarballs for SeaMonkey - I hope we'll have the buildbot infrastructure soon to do automated localized SeaMonkey builds again.
• Various Discussions:
  Message view pane, separate DOM inspector repo in hg, planning of upcoming milestones and releases, SeaMonkey Status Meeting, etc.

As a fun side project, I have started work on a new version of my old "Mandelbrot" application I did for my final paper in school, back then in Visual Basic. The application renders images of the Mandelbrot set fractal, the original application had nice zoom functionality and could even render the very similarly calculated family of Julia set fractals.
The difference this time is that this is a XULRunner application, rendering images into a <canvas> HTML element.
After getting rid of a number of early bugs in my code, this is (a thumbnail of) the first image I rendered with the color palette I ported from my old code:

The application is still quite primitive and unfortunately the JavaScript/canvas combination isn't the fastest way to do the math and paint the picture - the default 300x300 overview picture currently takes ~90 seconds of one of my Conroe cores being busy until it displays. When I get farther down the road with what I want from this app, I probably will open-source the code under the tri-license. This is mainly an educational project for me to learn how to do such a XULRunner app. Don't expect a finished app and/or something to try out yourself too soon though, this is just a fun side project - my main focus is of course on SeaMonkey!