GaleKid

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)

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

    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

    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.
    Continue reading

    Missing plugin feature in OWB.

    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:

    OWB mising plugin feature when flash plugin can not be found.

    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

    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

    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