The new approach is to have a very light-weight daemon running on the device which a host machine can interact with to run commands.  Most likely the host machine will be running a python scripts very similar to those our current test machines do, with the exception of issuing the commands over an ip connection rather than locally.

Joel Maher went about modifying the existing test scripts (see bug 493748 and maemkit for an example) to issue their commands over ip for windows mobile and I took the task of writing the light-weight daemon, which I called test-agent (code can be found here).  Its a very basic telnet shell with a few built in commands.

Everything is pretty strait forward with the exception of the exec command which attaches a debugger process to the executed command to capture stdout, since Windows Mobile ostensibly doesn’t have stdout. If anyone knows of a better way to capture output from a process, I’m all ears.

Today this set-up ran through all 437 xpcshell tests for the first time on a Samsung Omnia II.  This is a major step forward and everyone is pretty excited (Yay team!).

ShareThis

The first thing you’ll notice is the improved start up time. Brian Crowder took Vladimir Vukicevic’s original dabblings for Firefox on Windows CE and produced a cross platform fast start daemon for Mozilla.  Stay tuned to his blog for a post I’m going going to nag him to write about it. One caveat is that this faster start up time doesn’t take effect until after you reboot your phone (hey, this is Windows after all).

The next thing you’ll probably notice is the much improved panning. We’ve implemented a tile cache rendering system (much like you see on google maps) that allows us to cache previously rendered content and avoid duplicating the work.  This has also allowed us to switch over to native scrolling surfaces which has greatly improved panning performance. Roy Frostig goes into much greater detail on this in his blog post on the tile cache.

Also helping out panning performance has been Robert O’Callahan’s compositor work, which reduces the amount of native widgets we have to deal with when rendering or scrolling and a change to keep track of the invalidated regions ourselves rather than rely on the system do it.

But wait, there’s more! If you’re running a phone other than the HTC Touch Pro, you’ll notice we now support a wider range of screen resolutions through the use of CSS media queries, which really show’s the power of our XUL based front end. And if you are running on the Touch Pro, go a head and run your finger around the edge of the directional pad.  That zooming you see is the result of Alexandru  Cristei’s work to support the touch sensitive directional pad on HTC’s Touch phones.

There is plenty more work to do (after all this is an Alpha release), but in writing this blog post I realize just how much progress we’ve made since Alpha 2. I hope you’ll give it a try, put it through its paces and enjoy. Oh, and file bug reports.

Update: There is now a shortened url for the cab installer bit.ly/wma3cab

ShareThis

Since we started getting Fennec compiling on Windows Mobile a few months ago, we’ve made good progress:

• JeMalloc, the memory management library developed by Jason Evans and used by Firefox, has been ported to Windows CE and turned on for Fennec. This allows Fennec to manage memory much more efficiently.

• Fennec’s user interface controls have been rebuilt to be entirely CSS based. This will allow us to more easily adjust our UI for various screen sizes and resolutions in the future. Its also demonstrates how web technologies can be used to create compelling user interfaces. The look and feel will continue to evolve as we develop the product, but this release should give uses a sense of the direction its going in.

• Finally, this release also supports Add-ons. Add-ons are integral to promoting openness and innovation on the web and are unique to Fennec in the mobile space. Its been amazing to see how many great Add-ons have popped up already. Take for instance the gestures module created by Felipe .

As with previous releases, Madhava Enros has created a video walk through of this release.

Installation

This release has been targeted and tested on the HTC Touch Pro. We will be adding support for more devices in future releases. To install on your device, you can either navigate to this cab installer from your phone’s current browser or download it to your desktop and copy it to your device via ActiveSync. Once on your device simply click on the cab and it will install to your device. For more detailed installation instructions, look here and of course, please read the release notes.

Again, please note that some carriers filter web traffic to prevent their users from downloading cab files. If downloading the cab simply hangs or you get a message reading “This page contains erros and cannot be displayed,” this is probably what’s happening. In this case you will either need to be connected via WiFi or use the ActiveSync method.

The first time you run Fennec it will spend some time creating your profile. This may take a minute or two, please be patient.

Known Issues

It is not yet recommended to use this release for daily browsing tasks. Certain performance problems will become immediately apparent to the user. Panning has a noticeable delay between the user first touching the page and the page moving. We are certain that other less obvious bugs exist and we invite you to help bring them to light. You can find detailed information on how to file a good bug in bugzilla , our bug tracking system, here .

Looking Forward

Following the same path we took on Maemo, where the browser now performs quite well, development will now focus on performance improvements. There are known and suspected performance hot spots that need to be investigated and optimized. There are very talented people working on the core Mozilla platform who will continue to speed up things like JavaScript, graphics and the DOM. We are excited about a set of optimizations for drawing that take advantage of graphics processors, which will help Fennec’s graphics performance (i.e. panning and zooming). We are also looking at enhancements to our networking layer to optimize for high latency networks.

Now that we have gotten to this point, the fun really begins. If you would like to help us by testing or developing the product, please visit the Mobile Firefox wiki . There you will find some information that we hope is useful in helping you find where to “plug in” to the effort. As always, you can find us on irc in the #mobile channel .

ShareThis

It all comes down to memory.

Simply put, we were running out of memory. The frustrating part though, was that we weren’t running out of real memory. We were being constrained by an artificial limit of 32Mb (including the binary) that Windows CE places on each process. That is why otherwise extremely capable phones like the HTC Touch Pro with 288Mb of RAM were showing a beautiful checkerboard pattern. I’m still not entirely sure why this didn’t show up on our development devices before the release. I suspect it has something to do with the fact that we’re using unlocked HTC Touch Pros for development, while most of the testers seeing the problem were using handsets from Sprint, Verzion or AT&T.

Digging further, the reason people saw a checkerboard pattern, but otherwise usable UI is due in part to the way Fennec works. In Fennec, the user actually interacts with an html canvas element. We render the page off screen and then paint the image onto the canvas. In this particular case, it seems as though we were successfully rendering pages but failing to allocate enough memory to do the final paint onto Fennec’s canvas. We were handling this low memory “gracefully” and continuing to run.

jemalloc to the rescue

At first Doug Turner took a crack at cooling down this memory hot spot by improving on how we allocate memory during paints. Essentially, allocating a single buffer and reusing it every time he needed a surface to write to. This didn’t actually decrease the amount of memory we were using, but instead significantly reduced the amount of memory “thrashing,” (repeatedly allocating and freeing chunks of memory).

With that change we were able to run for much longer without running into memory problems, but it became clear that there are plenty of other places in our code that we thrash.

The solution was to use jemalloc, originally written by Jason Evans. Stuart and Vlad used jemalloc to greatly improve the memory performance of Firefox over a year ago, so it was already in the Mozilla bag of tricks.

Success!

Fearful of counting my chicks before they were hatched, I didn’t want to blog about this until it landed, and tonight it did. With jemalloc enabled on our windows ce build of Fennec I am able to start up without any worries of seeing a checkerboard.

…and I can browse to the two most memory intensive websites that I encounter on a regular basis (both of these have crashed my iPhone on occasion), the first being Planet Mozilla

…and the second being the Firefox tinderbox waterfall

I can even look at both at the same time!

With these bugs closed, we’re down to 5 blockers for our next release on Windows Mobile. Stay tuned.

ShareThis

There’s still plenty of work to do, but I can’t wait until we can benefit from Madhava’s upcoming small screen UI

Also, for any of you who attempted to build in the last 10 days, we did a pretty major rearchitecting that broke the build for a while. That has been resolved now and you should have more luck building.

ShareThis

ShareThis