How to support native interfaces on the Web

I posted an article about supporting native interfaces in Mobile Firefox. Byt the way, I found information regarding my post from here. This paper explained the native interfaces I talked as sensors on device and introduced how to send their sensed data to servers via the Web.

The sensor means a device that reads data from the user's physical environment. By the way, I am interested in how to get data from the native interfaces via web browser. I have not considered yet how a browser sends data to a server.
Anyway, this paper seems to be useful to extend technologies of web browser in a standard way.

Getting a location data from a GPS sensor was already realized on Firefox. Doug introduced this news in his blog and he implemented a prototype. I think it needs to be standardized

Performance test of the microB patches

I have tested the microB patches based on Mozilla1.9(Firefox3 alpha6 pre.)

- The microB package contains more 200 patches and several patch sets.
- It is released with Firefox3 alpha6 pre. now.

Two kinds of test case are used.
- Tinderbox DHTML Test
- CSS Rendering

Target Device : PAX320, RAM 256MB

And I got the following results on TestGtkEmbed in Mozilla.

* Tinderbox DHTML Test:
The microB patched Mozilla is 2.2 % faster than Mozilla1.9 (Firefox alpah6 pre).

* CSS Rendering:
The microB patched Mozlla is 5.6 % slower (?) than Mozilla1.9

I applied the default patch set of microB to Mozilla1.9

I can't understand why the microB patches is slow in the case of CSS Rendering.

The following items are performance related patches in the default patch set.

#Performance improvements
perf_addon/attachment.cgi?id=246204.diff
perf_addon/new_cached_scale.gtk2.diff
perf_addon/bug54205.diff
perf_addon/540_BUG54340_js_malloc.diff
perf_addon/545_BUG54340_findkeyword_inline.diff
perf_addon/550_BUG54340_optimization_options.diff
perf_addon/thread_wait_block.diff
perf_addon/spidermonkey_alloc.diff
perf_addon/605_css_erros_parsing_disable.diff

There are also some patches on Cairo.

I did not go through what each patch means.

Looking forward to your opinion & thought about the results.

Thanks

p.s. There is the same article on Mozilla newsgroup.

Teach yourself Mozilla in 5 days

Mozilla project and Senecac college have worked together on Mozilla related research and development projects. And they are opening some courseworks for Mozilla and open source.

The results are now posted on the project wiki so you can find various projects and technical reports made by students. Particularly, there is the lab of "Real World Mozilla" that leads students to learn and practice how to develop on the Mozilla platform from building to testing Firefox. It is also helpful to anyone who interest on development on Mozilla because it is documented well in the wiki.

In Korea, Daum corporation and Jeju national university made a open source related course together. So I think if they make and share the results related with open source projects, it will foster the proliferation of open source culture and movements in Korea.

Ideas on supporting native interfaces in Mobile Firefox

I'd like to share my ideas on native interface support in Mobile Firefox.
These ideas are based on Christian's Mobile Goal.
http://www.christiansejersen.com/blog/2007/11/20/mobile-goals/

Goal
Provide mobile web application environment which can use native interfaces.
- It can make XUL add-ons & web applications use native interfaces
through JavaScript

Types of Native Interfaces
(Most of mobile platforms support APIs for easy of use for camera, GPS, contact, and etc..)

There are two types of native interface:
* native interfaces from hardware
- GPS
- Camera
- Phone Call

* native interfaces from application engine
(HTML5)

libpng patch for Mobile Firefox

There are submitted patches for Mobile Firefox on the Mozilla wiki.
http://wiki.mozilla.org/Mobile/Patches

My colleague tried to apply the png patch to Mozilla and get a good result related to performance improvement.

As you know, we can build the libpng fixed point routines like the above patch.
(Use #define PNG_NO_FLOATING_POINT_SUPPORTED in mozilla/modules/libimg/png/mozpngconf.h )

In this case, he can get 8.6% performance improvement.
It's great. I think this patch is valuable to use on Mobile Firefox.

However, there is the following problem in this patch.
Mozilla handles some floating point values to get image information from the libpng so the patch commented those parts in the info_callback() function. (mozilla/modules/libpr0n/decoders/png/nsPNGDecoder.cpp)
The problem is that color management feature should get color profile information from the libpng. The following code shows the example:

void
info_callback(png_structp png_ptr, png_infop info_ptr)
{
...

if (gfxPlatform::IsCMSEnabled()) {
decoder->mInProfile = PNGGetColorProfile(png_ptr, info_ptr,
color_type, &inType, &intent);
}
...
}

We can check the value of gfx.color_management.enabled through the gfxPlatform::IsCMSEnable() method.

If the gfx.color_management.enabled is true, you can use the color profiles embedded in images to adjust the colors to match your computer's display. In this case, Mozilla should call the PNGGetColorProfile() method. But this method handles floating point values.

Fortunately, Mozilla sets the value of gfx.color_management.enabled to false as default. The PNGGetColorProfile() method is not called. Nevertheless, the patch commented this part because a user may try to set the value to true.
Anyway, the color management feature is not used basically now.


If Mobile Firefox should use the color management feature, the png patch needs more tweaks.

How do you think about that?