Thursday, November 05, 2009

Animating the Web(Kit)

After the landing of QGraphicsWebView implementation (in summary, a mimic of QWebView widget but for the QGraphicsView world) in WebKit trunk, your creativity is your guide :-)

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:



Nice stuff thanks to Qt and its QGraphicsView and QStateMachine flexibility.


--
--Antonio Gomes

Thursday, October 22, 2009

Cool news on QtWebKit

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.
  • Ongoing text drawing improvements in bug 24468.
  • Bunch of API reviews, clean up and bug fixes toward Qt 4.6.
Some remarkable related stuff include:
Afonso Costa and I are working on some nice stuff embedding all the above for maemo ... so I'd say to keep tuned ..


--
Antônio Gomes
tonikitoo at gmail dot com

Tuesday, June 16, 2009

WebKit/EFL 0.1 released

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 nice blogposts 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).


Building and Running WebKit/EFL (trunk)
  • git clone git://gitorious.org/webkit-efl/webkit-efl.git webkit
  • cd webkit
  • git checkout origin/master
  • git checkout -b <> # e.g. webkit-efl
  • get all dependencies installed - run |configure| to get a list of needed packages
  • WebKitTools/Scripts/build-webkit --efl --makeargs=<-s -jXX> --no-video # OR ./autogen.sh --with-port=efl --disable-video
  • WebKitTools/Scripts/run-launcher --efl
This 0.1 release has been tagged to "webkit-efl-0.1". Feel free to use it as well.

Where to get in touch

Join #webkit-efl channel on irc.freenode.net, send patches and emails ... Your contributions are be very welcome.

About the Development Team

  • Kenneth Christiansen (lead programmer) - kenneth dot christiansen at openbossa dot org
  • André Pedralho - andre dot pedralho at openbossa dot org
  • Antônio Gomes - antonio dot gomes at openbossa dot org
  • Diego Gonzalez - diego dot gonzalez at openbossa dot org
  • Afonso Costa - afonso dot costa at openbossa dot org
  • Marcelo Morais - marcelo dot morais at openbossa dot org

Monday, March 23, 2009

Running a text search engine in N810: CLucene

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.

Environment and requirements:
  • 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)
  1. 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 ...
  2. Out of 850 queries, 80 failed (for some reason) and 770 succeeded.
  3. No crash observed.
  4. Minor leaks (a few k's) observed in valgrind during the tests.
  5. 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.

Please comment if any idea comes.

--Antonio Gomes
tonikitoo at gmail dot com

Wednesday, March 18, 2009

Fennec (Mozilla Mobile) beta 1 released for n8x0 devices.

So, I am happy to broadcast the announcement of Fennec beta1 for the Nokia Linux devices. As pointed out by some Mozillia guys, this current release keeps agressively improving performance of the browser, giving to its users a boost of stability and responsiveness while surfing on the Web ... A

  • Feature-wise, flash player is supported now.
  • About the UI, I have not seen much huge differential changes for this beta, but fixes in what was already available have been making rendering, painting and panning a lot more usable then before too.
  • Startup time has been also hugely reduced, and it is really acceptable (~8 sec) now.
So, I'd say for those who have not installed it yet to give it a try, and so those who have, upgrading to this new beta should be automatic and smoooooth ...

There is a walkthrough video for this release. Check it out !

ps: also there is an on-going implementation of a gesture engine for fennec being driven by another Brazilian (Felipe Gomes) that can give it a taste of what is about to come soon ;)

Enjoy

--
Antonio Gomes

Monday, March 09, 2009

Running crossover'ed Google Chrome browser on Linux ...

Quick sharing: for those who do not want to install Windows just to test Google Chromium browser :), run it on Linux by grabbing a crossover'ed version from here ... or follow instruction here.




--Antonio Gomes

Sunday, January 18, 2009

firefox 2.0.x and 3.0.x + gcc 4.3.2 and Ubuntu Intrepid.

For those who do Mozilla development on Linux, and have upgraded to Ubuntu 8.10 (Intrepid Ibex), it might be important to notice that the gcc 4.3.2 shipped in that release fixes an old bug, and Firefox 2.0.x and 3.0.x built from source on Ubutu 8.10 will abort immediately after launching due to "buffer overflow". Problem is reported here and fixed partially on the mozilla trunk (1.9.2 and on the forked Firefox 3.1 tree), but many parts of the big patch are still missing checking AND they did not land in Firefox 2.0.x and 3.0.x development trees (old CVS system).

That is the patch that solves the problem for on both crashy trees, from Fedore mozilla team, iirc.

--Antonio Gomes