A week ago, I tried to quickly exercise what it is up to, and inspired in Kent's flipin widget idea, I got some cool rotation effects on the Web content. See the (amateur) show off below:
Two months past the last time I wrote something here, I realized things like:
1) these (trendy) micro-blogging thing make some people (including me) extremely accommodated and too lazy to blog; 2) I need vacations.
:-)
Well, now apart from these irrelevant personal feelings, I'd say that a bunch has happened in that meanwhile, and I will try to (slowly) get my to-be-blogged list freed ...
For now I will be sharing a some cool stuff that have recently happened in the QtWebKit land, project I am mostly spending my time on:
Kenneth and I landed the QWebGraphicsItem (now called QGraphicsWebView) implementation. In summary class makes it possible in an easy and fast way to have native GraphicsItem based object for Web rendering. See bug 28862([Qt][API] Add a new QGraphicsWidget based version of the "QWebView"). It makes it possible to have all supported transformations to happen on Web content.
Among other follow-ups to the above, bug 30162 made the "animated flip" feature a nice show case to the Demo browser.
Girish has landed support for "windowless" plugin to QtWebKit. See progresses and details in bug 20081.
"Holger landed his rewrite of ImageDecoderQt that significantly improves the memory footprint", said Simon Hausman is his blog :).
Bug 27214 created a webkit-qt dedicated mailing list.
The Browser team at INdT's OpenBossa Labs is proud to announce the 0.1 release of WebKit/EFL, a development milestone targeted the Enlightenment community.
We hope the release will give feedback about the overall usage of the web runtime and embedding API, as well as encouraging people in contributing to the port. Due to a change in focus, our team at INdT will have to minimize our envolvement somewhat, but we will still do maintenance and patch reviews.
Since the first announcement of the port during December last year, the code has been refactored in many of its crucial parts, resulting in good performance improvements. Now, six months later, we believe the project is mature enough to gain wider testing.
Quick start
1) About WebKit
WebKit is an open source web contents engine powering products such as Google Chrome and Android browser, Apple's Safari and iPhone browser, as well as Nokia's web runtime for S60.
2) About EFL
The Enlightenment Foundation Libraries (EFL for short) are a set of graphical libraries intended to provide easy-to-use resources for building rich user interfaces based applications. It is the core of the Enlightenment window environment. As mentioned in its official web site, "the libraries are meant to be portable and optimized to be functional even on devices such as mobile devices". Its core components are:
Evas: Highly optimized raster canvas
Edje: Declarative UI library
Ecore: Event loop and utility classes
Eina: Basic data types
Embryo: Scripting
3) About the port
WebKit was born to be toolkit independent: "WebKit's HTML and JavaScript code began as a branch of the KHTML and KJS libraries from KDE. As part of KDE framework KHTML was based on Qt but during their porting efforts Apple's engineers made WebKit toolkit independent". Currently there are browser components based on WebKit for the following toolkits (officially upstream only): Qt, Gtk+, wxWidgets, Windows, among others. This port is about adding EFL to the list of supported toolkits, providing an easy-to-embed browser component/widget into EFL based applications. As the developers also work on the Qt port, we try to keep the implementation as close as possible to that of QtWebKit. The build system was based on Gtk+'s though.
WebKit/EFL currently compiles and runs on Linux, and is not yet upstreamed, however tries to follow WebKit trunk as much as possible, though it might be a week or two behind.
_Painting
Painting is performed using Cairo on an offscreen surface, thus all painting is double buffered. For this to work on 16 bit devices such as the Nokia Internet Tablet, some patches needs to be applied to the shipped Cairo version.
_Networking:
Networking is based on Libcurl, which is used elsewhere by EFL, and was thus a natural choice. Cookies are supported.
What is in this version ?
API for navigation browsing (back, forward, reload, stop), session and global history, zooming, among others. See API here.
Configurable flash plugin via the "--enable-glib-integration" configure option. Default: true.
Configurable Windows like panning support via the "--enable-pan-scrolling" configure option. Default: false.
Performance
In order to better demostrate its performance (which is just great on Desktop), we have ran it on an Linux embedded device (in our case, an n810 running manoma). Alecrim, also from INdT, has written some niceblogposts about it. Below are two of the videos he made showing WebKit/EFL running on a n810 with mamona.
Andre Pedralho is also updating EVE browser to work with this version.
Some highlights about the performance is the startup time: ~3 secs on cold launch and ~1 second on hot launch.
Known issues
Flash crash on GMail.
Flash content not zooming synced with page content zooming (This has been disabled due to Flash Player issue (FP-2140).
A search engine is, from a high level view, a computer program that comprises at least two tools: an indexer and a "searcher", both to work over some given content. Going deeper a bit on it, the indexer part would be the responsible to identify all of the terms in a document or corpus and builds a table (or whatever) that indicates where the terms are used. Basically it maps a term to documents it appears. On the other hand, the searcher is what makes it possible to perform quick queries over this indexed content.
Well, what about all this, on a maemo context ?
Scenario
Lately, André Pedralho (a co-worker at INdT) and I got a demand for a product we are working on to benchmark a text-based search engine on an ARM platform having as final goal to find out a feasible candidate to be embedded into a web browser.
After some research for good, stable and open source search engines available, CLucene (a C++ port of popular Java Lucene) came to scene as promising option, and so we ran a couple of tests against it to check its feasibility as described below.
scratchbox set up with rootstrap and compilers for building to maemo platforms, as described here.
a patch to be applied against CLucene (only some files in clucence/src/demo change), that makes it possible to perform some stress tests over it.
Benchmark (stress test)
To perform the tests, it was indexed a 16Mb textual base set (by using CLucene itself) resulting in a 18Mb index ready to use.
In the patched CLucene demo, there are 850 words to be used to query the indexed base against each of them programatically, and measure the time taken by complete the batch, as well as reliability, leakage and CPU and RAM memory usage of CLucene during this stress test.
Results: (from a N810 device w/ chinook)
850 queries were executed in around 45 seconds (so it took in avarage 0.05 seconds per query). It is also interesting to mention that it was on ARM 5 seconds slower than my Desktop machine, with dual core processor, 4Gb of RAM and so and so ...
Out of 850 queries, 80 failed (for some reason) and 770 succeeded.
No crash observed.
Minor leaks (a few k's) observed in valgrind during the tests.
Acceptable memory and CPU usage (given the amount of queries performed in so short period) as shown in the figures below
Although CLucene has been shown itseft as a promising option and others (i.e. the mozilla-based browser Flock) have successfully embedded it as a content search engine, it is pretty much early to say something more concrete as a conclusion about CLucene. A next round of tests will be performed soon these days, including a measure of how fast it updates its index on-the-go, as well as how good its concurrency handling is, and all it running over a bigger indexed content.
Inspired by our own need and other's, a couple of friends (André, Roberto and Tomaz) and I decided to increment Firefox' default find feature.
Story
If you use Firefox, you had probably used the Firefox' findBar already. It is the simple and intuitive way users have to search for words in a web page. The main thing we "miss" is that it requires the user to type the exact (set of) word(s) he searches for to actually find it. Sometimes, however, lazy enough users *like us* want to just give the findbar a "clue" of what we want to find in the page, and even often just do not know. The result of that was the SmartFind addon for Firefox 3.x. From its site we have some usecases of SmartFind:
"Schwarzenegger". This looks easy when you are looking at the word, but what if you do not have any idea what to write? Then you wonder "I would like to write something like "chuazenger" and for it to find similar words in the page".
As another example, when you are on a page where accents are used and your keyboard is not configured to type such accents (~^`), the traditional find method will not be able to match with any word.
You are just lazy like us and terrible in orthography :)
HOW
Smartfind ranks how similar each word in the page (yeah, that might take time depending on the webpage ... heuristics exists to speed it up, but new ones are welcome) is to the given word (input by the user). For such, we are implementing the levenshtein distance metric. The "how similar" can be trigged by the user through the Edit->SmartFind menu, to be more or less restrictive.
Well, in practical terms, whenever Firefox' original find method does not find something, SmartFind takes place and hitting a aditional "enter" fires its actition ...
If it is still not clear, see sshots bellow:
User is not from Austria and does not know how to spell this-big-name-above.
SmartFind finds it for him.
Disclaimer: This is just the first and quickly implemented public release, so there are some known problems:
Improve the way it gets text content from the webpage (better xpath expression, which ignores "object" , "style" , "script" tags' text content).
Fix problems with line break (lack of "br" tag) .
Implement an user-intuitive way to walk through the list of most similar items found: currently we are static to the top of the list.
Implement a fuzzy third state (similars ?) while comparing chars that could make SmartFind work much better: "for example, consider 'ë' as not completely different from 'e' or 'é' but similar". That done, the Finnish word "päivää" would be more similar to "paivaa" and so on ...
Bosses are only pleased when they get numbers and charts in reports on top of their tables. At this round, we (André, Diego, Fernanda and I) had to benchmark Mozilla and Gtk-Webkit on arm, and so we did ... Text below is an informal summary of the official report.
Scenario
Experiments were performed using Nokia N810 Internet tablets (400MHz CPU and 128Mb of RAM memory) with Chinook installed.
Applications under test were GTK+ embedding sample browsers from both Mozilla (TestGtkEmbed - available from the mozilla-central repository) and WebKit (GtkLauncher - from the WebKit trunk), cross-compiled in Scratchbox 1.0.8, gcc-2005q3-2.
About the tests
These were the items measured:
1. Page load speed
The page load test focuses on measuring the absolute and relative time needed by each browser to open a given set of locally stored webpages. The test is driven by a JavaScript script that fires the load of each page in the test set. Both the time speed for each Web page to load (relative time) and the total time taken by loading the whole set (absolute time) are measured. The test set is formed by 37 real-world webpages fetched using the httrack crawler and is accessible over an Ad-hoc wi-fi network via the Apache Web server.
2. Memory and CPU consumption of 1)
The goal of this test is to evaluate how well browsers manage system memory during the page load test (above): virtual and physical memory allocated by each browser were monitored and printed out in a comparing chart. As such, a Bash script was developed to "watch" system memory and CPU numbers. It is basically a timer used to poll at every 1 second the browser's virtual and physical memory values from "/proc", and CPU usage from "top" (in batch mode).
3. Javascript engine performance.
Both browsers were ran against Dromaeo and SunSpider Javascript test suites and memory consumption during these tests was measure (same way as in 2).
4. CSS compliance
Both browsers were ran against Acid3 CSS test suite.
Results and Charts
As there is no such general browser benchmark suite (is this even possible ?), we just developed your own tools (bash and JS) for those item above that do not have renowned public benchmarks available (pageload and resource consumption).
ps: I tried Mozilla's Talos suite, which seems fine to test Mozilla but it is not portable for other browsers.
1. Page load speed
Mozilla's and Webkit's page load speed against the given pageset (see table below).
Individual pageload speeds (in ms).
DISCLAIMER
Original page set was formed by 85 webpages, from Talos Mozilla Test Suite. Although TestGtkEmbed ran well through the entire original testset, GtkLauncher always got OOM-killed after a while running the page load test, due to lack of memory (see memory chart in Memory Consumption section). Then, from the original 85 webpages, 37 were chosen to make GtkLauncher to finish this test.
10 out of 37 of the remaining webpages in the pageset contain non UTF-8 characters (Russian, Japanese, Chinese, ...). While WebKit misrendered most these fonts, Mozilla went fine for all. Example showed below:
www.3721.com in TestGtkEmbed
www.3721.com in GtkLauncher
2. Memory and CPU consumption during 1)
Memory consumption while doing page load test in 1).
UPDATE: VIRTUAL AND PHYSICAL MEMORY LABELS ARE CHANGED HERE.
CPU load while doing page load test in 1).
3. Javascript engine performance.
Dromaeo numbers.
SunSpider numbers.
Browsers memory use while doing Dromaeo.
Browsers memory use while doing SunSpider.
4. CSS compliance
Mozilla on Acid3.
Webkit on Acid3.
Conclusion
Some outstandings from the numbers:
Mozilla managed better memory while doing page load tests, although Webkit was faster. It might probably been had affected by the fact that Mozilla rendered well all non-western chars, Webkit fails.
Webkit was faster and used less memory while doing both Dromaeo and SunSpider test.
UPDATE: Some things that have to be pointed out about my Mozilla build are:
I do not jemalloc enabled, but would love to.
Mozilla guys are doing some amazing job on speeding up their Javascript engine: tracemonkey will probably get things much (5x at least ?) faster.
ps: I personally would not mind to do a 2nd recond of tests and charts w/ these two items above enabled in my Mozilla build.
So, the much anticipated Mozilla Summit08 has just finished, and regardless someunforeseen, I truly believe that most of the 400 (+-) attendees had an amazing time, as so did I. Follows some of my highlights:
Dan's team did really well on organization ...
I had chance to see some really nice mozilla guys again including: both the father and grand-pa :) of mozilla mobile, dougt and choffman, respectively; the long term mozilla contributor on linux and always elegant, cblizzard; the mozillabrazil driver mgalli; as well as the nice leoz, romaxa and timeless from the microb project.
I met the famous Stuart ‘Pavlov’ Parmenter and got some nice advices about browser benchmarks, steps toward a rendering server firefox, as well as about some of the huge Javascripts speed up they are about to land in Firefox 3.1 (new JS is going +- 10x faster then the current) ...
I wish to have had a shorter trip back: 7hs (from whistler to vancouver) + 5 hous waiting + 5 hous from vacouver to toronto + one hour waiting + 12 hours from toronto to sãopaulo + 12 hours waiting + 4 hours from sp to manaus = 46 !
It sounds like another buzz-word candidate on the internet field is the term "RIA": many big guys commercially interested on RIA seem to concept it differently. My understanding about the term stands on its origin: RIA are applications running of top of browsers essential features and infrastructure: connectivity, interoperability, cloud storage (data available anywhere, any time), responsiveness, and so on, and IMO this is what drives the real meaning of RIA or "Rich Internet Applications".
PS: To avoid ambiguity we are generally referring RIA by "web applications".
In that sense, the Mozilla Prism project was launched w/ the intention of "integrate web applications with the desktop, allowing them to be launched from the desktop and configured independently of the default web browser". The project implements new concepts including "SSBs" and "distraction free browsers". Ok then, lets analyse what we have here from different perspectives:
On the pc (w/ satisfactory processing capabilities), users can have their web browser w/ many tabs opened, their RIAs living each one on their own process and windows, as well as many other OS applications all at the same time and their PC are able to run great.
But what about it all on the mobile space ? To be honest I am not really sure about the answer, *but* that is what this port job is mainly about: getting feedback about what maemo users get when they can somehow to integrate common WebApps (meebo.com, gmail, gdocs, gchat, ...) with their mobile desktop environment.
Although the TODO list is still big, the DONE list is accomplished so that it worth making "Prism to Maemo" project public.
1) Installation
While I am still having trouble to get my upload account to 'Maemo Extras" repository working fine, I've set up one living under my personal web dir: .install file here.
2) Warnings
I will be working on this more seriously from now on with guys (luckily on #prism - irc.mozilla.org) to see what features are really interesting to have available on the mobile/maemo space.
It is still an "under porting" work. so bugs are likely to be found and new releases are likely to appear.
.deb sizes 10Mb and installed it takes 30Mb on disk.
Since a while I've being paying some attention into the promising Mozilla Prism project (old WebRunner), specially over a mobile developer perspective. Prism is a Mozilla Labs advanced development project that provides "a simple XULRunner based browser that hosts web applications without the normal web browser user interface". More interesting over is that the project came to me at the same time philip van hoof blogposted about "Web 2.0 email clients" (or something like this). My post could even get titled "mozilla-based web 2.0 email client" (or something like this), but Prism goes far away forward from that.
Main concepts here are two: Site Specific Browsers (SSB) and Distraction Free Browser:
SSB: applications with an embedded browser designed to work exclusively with a single web application (whereas typical browser chrome are rarely used). It doesn’t have the menus, toolbars and accoutrements of a normal web browser . An SSB also has a tighter integration with the OS and desktop than a typical web application running through a web browser.
Distraction free browsing: "This is nice for those times when your have to have your web based email and docs open but you don’t need the distraction of the rest of the Internet keeping you from your work. Plus the memory footprint is kept to a minimum because it isn’t the ‘full’ browser and all of its extensions."
Could that interest users of mobile devices ?
Not sure about the answer, but I put some effort on that these days to answer this question with some practical stuff. First, I got blassey's xulrunner armel build for maemo, checked out prism source from svn, pulled Firefox 3 pre beta 5 source base (to work as my mozilla build system), built them all together and after some hacks I got Prism running on maemo OS 2008 w/ some webapps (meebo and gmail for instance).
I will try to get some thumb enabled set UI for it, as well as making a .deb/.install available for Prism to see how things go from a mobile user perspective ...
PS: Prism has nothing to do with web application development, it's simply providing a more desktop-application-like interface for web applications. Mozilla claims: "Unlike Adobe AIR and Microsoft Silverlight, we're not building a proprietary platform to replace the web ... Prism isn't a new platform, it's simply the web platform integrated into the desktop experience. Web developers don't have to target it separately, because".
UPDATE: Greetings to MFinkle and other for all work on this.
Wladimir Palant, the original Adblock and Adblock Plus Firefox web-addon developer, among other complainings, has pointed out an important security hole in initial version of the Adblock Plus Microb port :
"... So I downloaded this Adblock Plus version and soon it was obvious that it is inserting an Adblock Plus button into all web pages the user visits — using my favicon as the image on the button. Which makes me the lucky guy who can track every move MicroB users do on the Internet (at least if I decide to send HTTP headers preventing caching)."
Happily, Andre Pedralho quickly fixed this issue and uploaded the 0.0.2-1 version of Adblock Plus MicroB port in a few minutes. It is highly recommend for all Adblock Plus (maemo port) users to update their packages to the newest as soon as possible. For the other raised issues by Wladimir in the post entry, including changing the addon port name, we are investigation how much we've changed from the original source to take the proper action.
These past days, I've been testing the just released version of Spellcheck extension for MicroB, and I'd say that even with all MicroB UI constraints for addon development including no XUL, XBL, overlay (no extensible UI) it is a great work.
Follows some usability scenarios that could be improved, though (spellcheck has to be installed).
Through "about:config" page, set the "layout.spellcheckDefault" to '2' and go to default browser home page.
Install the russian dictionary, and change you default input method language to Russian as well.
Mistype any word in Russian and it won't get underlined (indication a mistyping), once the default 'en-US' dictionary is the one in use.
It is not possible right now to users to switch the a dictionary w/out having to mistype any word in the currently used dictionary language, double tap it, and change the dictionary from the prompted Select dialog. Suggestions ?
I am a user and I want to know what is the currently used dictionary , how to do this ? Only going to 'about:config' and searching for 'spellcheker.dictionary' value.
Couldn't it get indicated in any of the dialogs' title that spellchecker prompts out ?
After installing Greasemonkey addon on MicroB, my n800 browsers much better: first I showed how users could better youtube from MicroB, and now just a quick update on how users can also better google search on your device: mine install google greasemonkey script, for example, add videos, images and wikipedia top 5 search results alongside normal google searches.. All this through AJAX !!!! It ends up like:
Better than surfing on the Web from everywhere is doing it all on your way ! On that regard, Firefox is really a pioneer: its robust Addon backend and online support make possible to customize your browsing experience in a few clicks. think that Browser-extras project is a way to go in order to get MicroB closer to Firefox.
From an user point of view, I see it as a really great and promissing initiative but how about from a MicroB extension developer's prospective ?
Some differences between MicroB's Addon system and Firefox' one make extension development for MicroB a bit more painful then it should: Firefox counts on some built-in mozilla technologies that are disabled in compile time in microb-engine:
XBL (XML Binding Language): "an XML-based markup language used to declare the behavior and look of XUL Widgets and XML Elements".
We lack manpower to improve this development environment specifically ... =/ But the project is on regardless that, work is being done, and some results are already out there.
So, since Monday (Jun/25) I've been in São Carlos (São Paulo) in order to get in touch with Marcio Galli (taboca - thanks for the hospitality) and brainstorm about some ideas we have. In resume, what I can say is it was very productive trip.
Marcio has been involved with web technologies and mainly Mozilla stuff since early Netscape times (back to 1997 or so), so his background in his area is notable. Basically, we talked about some general MiniMo issues, like usability and features, as well as ways of pushing it to Linux devices (maybe OpenMoko ?).
In that sense, I could show him MiniMo running on the n800 device, and I asked him about what could be done (UI-wise) to improve n800 users' web surfing experience. I got good input on this, and I hope to be packing them up in minimo 0.21 for maemo soon.
The last day (Jun/27) was the best one. I got some minimo upstream Linux specific bugs under my responsibility, which is great and will take me definitively to the XUL world. Furthermore, Offline Browsering and OS Firefox were subjects of a nice talk we had in taboca's office. I will be blogging about it specifically soon as well. Loooooots of ideas came up .....
Happily, I could also participate to the Mozilla Community Build Brazil, an community effort event which intends to learn more about Internet habits of specific countries and find out local ways to spread and increase market share of Firefox in them. It is been headed by Asa and JT from Mozilla. Here are some pics of it. They realized, for example, the potential of orkut in Brazil, and so why not making "Firefox as an easier Orkut tool" for almost 20 million users here ;).
Btw, I will be working on a Firefox extension for orkut my free time (more about it later on) !!!
Today Francisco Keppler and I took a free time off to check the feasibility of running Minimo on OLPC and these what we got:
minimo on OLPC
hack hack hack ...
Nice, isn't it ? Results are really promissing: minimo fits to the environment, scrolls fast and it is now very user friendly. Well, it is basically a raw version on minimo 0.2 (pulled down from MOZILLA_1_8_BRANCH on Mozilla CVS) running on a debian running a OLPC hardware (by francisco keppler).
ps: a HOWTO is coming ... ps2: minimo maemo port 0.2 is coming soon as well ;)
