OWB

GaleKid

mariobensi — Mon, 15 Dec 2008 10:08:47 +0000

Welcome to Galekid!

Galekid is the new release of OWB. It brings these new features/facilities:

cmake refactoring to increase performance
BAL refactoring:
- remove OWBAL and WKAL namespace
- remove Concretizations directory
- create a subdirectory WebCore, JSC or WTF to group the files correctly and apply the good compilation flags.
- move Base to the root directory because it’s used by all the project and a part of it is exposed.
OWB API clean-up and correctly exported.
Fonts refactoring to extract the drawing part to ease the FreeType or Generic port to other graphic platforms.

Galekid has now moved to the OWB trunk:
svn co http://www.sand-labs.org/svn/trunk

It will be tagged as the official OWB v4 this week after a week of public tests and feedbacks.

Enjoy your tests and thanks for your feedback!

Build System Redesigned (part one)

olivierdole — Mon, 15 Dec 2008 09:57:32 +0000

Hi,

No this blog is not dead but a day is only 24 hours.
As you know OWB build system relies on CMake. Unfortunately many things in our current build system are not done properly. Here is a list of things which could be improved:

If you try to compile the trunk with cmake-2.6 you will get many warnings about cmake policy

Code inside CMakeLists.txt becomes unsustainenable. Typically, code for generated sources is quite ugly. Indeed from my point of view a huge advantage of CMake is modularity and we do not enough take advantage of this.

The current build mechanism does not currently accounts Webkit for a web rendering engine, which should therefore be seen as a library and not export all its symbols, which gives a strong penalty on embedded device due to symbol relocation. If you want more info about that I suggest you to read this excellent paper from Ulrich DREPPER on how to write a shared library.

Option naming and coding covention inside CMakeLists.txt did not really exist.

Thus during the last months when I had time on one’s hands, I have rewritten from scratch CMake build system for OWB with the following goals in mind:

Getting only one final shared library at the end of the build instead of having something like 12 shared libraries.

Easing new port integration inside build system

Cleaning CMake and taking advantage of CMake modularity

Using as much as possible new CMake-2.6 features

Of course this redesign has an impact on how to integrate a new port to OWB, but this will be the subject of a future post which will explain the new architecture.

Olivier.

SVN commit hooks and Twitter

jcverdie — Thu, 09 Oct 2008 21:16:13 +0000

It may sound slightly off-topic but here’s a new way to track down OWB development. There’s now a twitter user called Origyn you can follow to get svn commits.

To do this, I used svnnotify to send the mails and put together the informations, and TwitterMail to tweak twitter’s status from email since Twitter does not (yet?) provide an email bridge.

The set-up is pretty straightforward using debian or ubuntu svn server:

sudo apt-get install libsvn-notify-perl

then edit post-commit in your hooks directory and add the following line:

/usr/bin/svnnotify –repos-path $REPOS –revision $REV -x YOURADDRESS@twittermail.com=”trunk|tags|development”

This will prevent commits on directories others than trunk and tags to be publicized.

I also had to tweak svnnotify since it uses multiple dashes as commit log separator, which were misinterpretated as mail signature and then withdrawn from the notification… Too bad, huh and also to limit the length of the email, too be concise in order to fit in twitter limitation, and to add instead of the number revision, the URL of the whole changeset…

Jean-Charles

Shinny Chrome

jcverdie — Wed, 03 Sep 2008 21:30:57 +0000

Guess what ?

As anybody on Earth working on the Browser ecosystem, I’ve burnt out most of my day with Chrome, and more precisely Chromium.

Downloading sources, V8 sources, downloading Windows Binary and digging my office to find where my Vista license was. And, of course, answering a lot of emails and phone calls of concerned customers about whether we should/could/would switch to Chrome or to V8.

This is a first quick post about it, but some items are already clear enough to talk about:

Chromium uses WebKit as its HTML rendering engine. Looking at the sources, it seems that Google is yet to deliver a lot of changes in WebKit, so they’ll end up in OWB since we are never more than 2 days old from WebKit tip-of-tree.

Chromium also performs WebKit merges, using a different way from us. I’ll wait and see for metrics about their performances to regularly merge from WebKit to see how it performs. We are still able to merge WebKit 3 times a week in lest than a couple of hours.. While build time is downgrading that metrics dramatically

Chromium uses scons as a build configuration tool. We’re not anywhere from dropping CMake support, but investigating elegant alternative is always an option.

Chromium uses a brand new JS bytecode compiler, V8. We’re already investigating what it takes to have it running with OWB. Still no idea, could be simplissimo or hard-as-hell. But one thing is sure: until the dust comes down, we need to be able to give rationales about it to our customers and prospects. I’m pretty sure that at a certain point, V8 will end up as a CMake option in OWB configuration, in replacement of SquirrelFish. But it might not be that easy.

As you know, my company, Pleyo, targets CE world. On this world, Intel architecture are not (yet) dominant, so it’s a good news to see that V8 is already ARM compliant. We are also investigating what’s the path to support other architectures and at what point V8 is really ARM-compliant. And how it’s behaving on these architectures!

As a food for thoughts before we can give any insight about that potential V8 integration, here are some metrics about the so-much commented V8 performance tests:

It clearly shows that OWB is way behind Chrome, but outperforming other configurations.

Now we need to perform the same tests on our references embedded platforms… But we’ll need more input from Google about Chrome first

[ED. NOTE: The bigger the figures are, the best]
[ED. NOTE2: I've updated the table with Chrome running on Wine (to save perfs and be fair!), I've also added SunSpider to give a perspective to the google home-made metric!]
Jean-Charles

Missing plugin feature in OWB.

olivierdole — Tue, 02 Sep 2008 16:55:25 +0000

Here’s a new tiny feature for OWB, the “missing plugin” for the SDL port. This feature is quite simple to understand as its goal is just to display a default image when a page expects to use a plugin which could not be found on your system. Of course to enable this feature, you need to enable NPAPI support in owb and also SDL graphics port. Below a screenshot of the result:

Of course this new feature can be improved. So if you find bugs, do not hesitate to file a ticket on OWB trac. And if you can provide a patch to fix the bug, it’s always better

From my point of view the next steps about this feature could be the following:
- Do the same thing for GTK port and pull the resulting patch to webkit-gtk guys.
- In the same way, implement the “disable plugin” feature to warn OWB users that NPAPI support is disabled so that OWB won’t be able to display any plugin content.
- And of course, fix bugs related to this feature.

Olivier

Hunting memory leaks

olivierdole — Wed, 23 Jul 2008 13:52:28 +0000

I’ve been working recently on hunting memory on OWB.
During my tests I realized that I was able to make memory consumption increase to hundreds of mega just by scrolling !!! So the obvious solution was to run valgrind to understand where the leaks occur.
The first huge trivial leak was about Font::drawGlyphs() method. In the previous OWB release text was drawn in a BCNativeImage and it was up to BCNativeImage to free its data but it’s no longer the way it works in OWB v3. So I just had to add a delete glyphRGBABuffer to remove hundreds of mega of leaks. The fix can be found here.
Nonetheless even after this trivial fix, there was still many megas of leaks due to fonts. I have immediatly seen that it was due to a recent improvement from me in font drawing algorithm (still in Font::drawGlyphs() method). I simply forgot to release FT_Glyph data which means for a page with a lot of text, tons of leak. This fix was a bit more tricky because if I simply did a FT_Done_Glyph on the structure, I immediatly got a segfault. That was because I incremented a pointer inside FT_Glyph structure… So I simply created a temporary variable to store the address and to be able to modify it. Of course I was so proud of my fix that I forgot to fully test my fix and after a while I was smashed with a huge regression due to my fix. So I have to correct my previous fix with this one.
Finally I have also fixed some other trivial leaks to have a nicer valgrind report. Below a leak summary (a SDL version with all options):
==17568== LEAK SUMMARY: ==17568== definitely lost: 1,576 bytes in 14 blocks. ==17568== indirectly lost: 8,571 bytes in 218 blocks. ==17568== possibly lost: 0 bytes in 0 blocks. ==17568== still reachable: 1,579,458 bytes in 9,921 blocks. ==17568== suppressed: 0 bytes in 0 blocks.
Of course there is still a lot to do to fix all leaks but I think that’s a good beginning.

Olivier

Welcome to OWB

jcverdie — Tue, 22 Jul 2008 21:05:40 +0000

Welcome to OWB, Origyn Web Browser. OWB is an opensource web browser, based on the fabulous Webkit engine. OWB aims to be a web rendering engine just as WebKit is, but making it easy to adapt to the Embedded World.

The official website for OWB is hosted at Sand-Labs, http://www.sand-labs.org/owb.

Sand-Labs.org is an opensource community aimed to host projects whose interests are in CE devices and the Web. Sand-Labs.org primary sponsor is Pleyo, a french company, Montpellier-based. Others projects however could end up at Sand-Labs.org, heads up

In this blog, we intend to improve the communication over Origyn Web Browser, explain our choices, our policy, how and where we’re heading to!

Jean-Charles