The roads I take...

KaiRo's weBlog

März 2024
123
45678910
11121314151617
18192021222324
25262728293031

Zeige die letzten Beiträge mit "Mandelbrot" gekennzeichnet an. Zurück zu allen aktuellen Beiträgen

Populäre Tags: Mozilla, SeaMonkey, L10n, Status, Firefox

Verwendete Sprachen: Deutsch, Englisch

Archiv:

Juli 2023

Februar 2022

März 2021

weitere...

24. August 2015

Ending Development and Support for My Add-ons

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):
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.)

Von KaiRo, um 17:14 | Tags: Add-Ons, Data Manager, download manager, Firefox, Mandelbrot, Mozilla | 4 Kommentare | TrackBack: 0

22. September 2010

The Speed of JavaScript in SeaMonkey

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:

Image No. 22441

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; 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. :)

          Von KaiRo, um 18:10 | Tags: JaegerMonkey, JavaScript, Mandelbrot, Mozilla, SeaMonkey, SunSpider | 4 Kommentare | TrackBack: 0

          29. Mai 2010

          New Add-ons: Mandelbrot, Data Manager

          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. :)

          Von KaiRo, um 15:29 | Tags: Add-Ons, AMO, Data Manager, Firefox, Mandelbrot, Mozilla, SeaMonkey | keine Kommentare | TrackBack: 0

          3. August 2009

          Progress on XULRunner-based Mandelbrot app

          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.

          Image No. 21897

          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:

          Image No. 21895
          (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. ;-)

          Von KaiRo, um 00:51 | Tags: artwork, Mandelbrot, Mozilla, N810, SeaMonkey, Wallpaper, XULRunner | 3 Kommentare | TrackBack: 1

          19. April 2009

          Linuxwochen, Mandelbrot-Demo, MozCamp Wien

          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!

          Von KaiRo, um 20:39 | Tags: Linuxwochen, Mandelbrot, MozCamp, Mozilla, OpenWebCamp, SeaMonkey | 4 Kommentare | TrackBack: 0

          3. September 2008

          How Opening The Source Helps You

          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.

          Von KaiRo, um 17:00 | Tags: Mandelbrot, Mozilla, XULRunner | keine Kommentare | TrackBack: 0

          23. August 2008

          KaiRo.at Mandelbrot Going Public

          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:
          Image No. 20151
          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!

          Von KaiRo, um 19:39 | Tags: Mandelbrot, Mozilla, XULRunner | 6 Kommentare | TrackBack: 1

          How Fast Is TraceMonkey In Real World?

          Everybody is writing about TraceMonkey today, the just-landed-on-trunk version of the SpiderMonkey JavaScript engine with "tracing" JIT compilation for speeding up code that is run repeatedly.

          What I wondered is how fast it is in code that is no benchmark but stuff a real application might use. And as I have my "Mandelbrot" fun project as a XULRunner app (see the last paragraph of recent status update post), which naturally does a lot of looping over the same equation, so I thought it might be a good candidate for optimization.

          So I fired up the XULRunner app, doing four testruns of "time mandelbrot" (launching a script that runs my XULRunner build from today's trunk code under primitive unix time measuring) and looked at the amount of user and sys time used. I didn't want professional benchmarks, I wanted just a rough estimate of real world numbers, so it was OK that I needed to manually click the "Draw Image" button and manually click "File > Quit" once the CPU usage came down from fully using one core. I only wanted rough numbers to see if there's a visible difference, so I could live with those deficiencies and rounded the average of two runs roughly.

          For the unoptimized, heavily JS-object-based approach I already had last week, I got a number that was about the same as I estimated previously - about 96 +/- 2 seconds. When I turned on the javascript.options.jit.chrome pref to run it with TraceMonkey, I saw no difference though, still the same, quite slow run time.
          But even though Z = Z.square().add(aC); looks good for the Z = Z² + C equation, it's not that efficient to do two JS object creations for every iteration, so earlier in the week, I replaced that nice code with pure math and simple variables only. That helped performance a lot and saved about 90% of the time, cutting it down to about 9.4 +/- a half seconds.
          Having that code activated, I turned on TraceMonkey once again. And now, it really helped: 7 +/- 0.2 seconds! That's about 30% faster!

          For already optimized, pure JS math code (which is probably more real-world than nice-looking object stacking), squeezing even 30% more performance out of this calculation is surely nice!

          Still, running my old Visual Basic 5 application under Wine has, apart from more features, two advantages to this XULRunner app: For one, it updates the image frame in the UI during calculation and not only at the end of execution, which is better felt performance as you see what it's doing. For the other, it's still 20% faster, using about 5.6 +/- 0.2 seconds with the same instrumentation - and that though people say VB is so slow. Bummer.

          So, good work done, TraceMonkey friends. But there's still more potential to use the CPU more efficiently. Keep on the good work!

          Von KaiRo, um 03:45 | Tags: JavaScript, Mandelbrot, Mozilla | 4 Kommentare | TrackBack: 3

          18. August 2008

          Weekly Status Report, W33/2008

          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:
          Image No. 20151
          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!

          Von KaiRo, um 04:10 | Tags: L10n, Mandelbrot, Mozilla, SeaMonkey, Status | 3 Kommentare | TrackBack: 1

          Feeds: RSS/Atom