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.
