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.
