[webkit-dev] YAPP Yet another porting project

[Mike Emmel]

I'd like to let the webkit team know there is now another porting
project underway.
This is a port of webkit to directfb. Directfb is and alternative
graphics api that provided direct
framebuffer access and full alpha blending of windows. It used in
numerous embedded linux projects and for the debian installer. It
allows transparent support for use as a single application dedicated
environment linked as shared libraries or as a multi-application
desktop using a ipc library call fusion similar to Mach services.

Right now it consists of a port of GtkWebcore on top of gtk/directfb
which was recently added as a new backend to gtk.

It consists of two cvs repositories in the directfb cvs.

See http://www.directfb.org

The first checked in under cairodfb/demontic  is a lightweight font
management api on top of cairo. Cairo has very weak font handling and
this is a rewrite of  parts of libxft to work on top of cairo over
time its hoped that it will become a reasonably powerful but small
text layout engine.
I noted in other posts that the win32 backend is using cairo I'm very
interested in what the plans are for font management outside of that
provided by cairo.

Next as far as using cairo for the core rendering I feel there may be
a need for a simple integer direct drawing api that uses cairo
surfaces I'm considering adding this also if its really needed it will
have functions such as fillRect and blits etc, that use a integer or
pixel based coordinate system the primary use case is to have a very
fast path for basic operations. I'd like to know if this is of intrest
also.

Next the ported GtkWebCore code is in WebBrowser/GtkWebCore.

The inital plan is to upgrade this port to the latest WebKit code
probably as soon as WebKit is reasonalby stable.

Our long term plans are pretty big.


We want to develop a XML centric application environment on top of directfb.

First Directfb has a lightweight widget set called lite :) the plan is
to get the core engine
ported to cairo/svg and a small number of platform widgets such as
text entry, scroll area,
draw area and develop the rest of the widgets in SVG/(XUL ??) this
gives a very portable and configurable implementation.

The gtk support will be reported to wrap this core engine and
potentially provide native replacements for the SVG widgets.

Since we want the browser to be our application programming api we
would like to break it out into three independent modules.

1.) URL/Mime/DOM/Javascript engine for us this would run as a fusion
service similar to a mach service it communicates via shared memory in
a multi-app environment.

2.) Rendering engines for various XML's  with only SVG/(XULish) as
core engines.

3.) Everything else user and system wide preferences bookmarks actual
browser or domain specific application, management of additional
xml/rendering  engines etc.

Finally if thats not enough I'm also working on a llvm compiler (
apple is to :) under the gcc gcjx branch.
Its currenty not far along and targeted for java but I'm designing it
to work as a generic object oriented AOT and JIT compiler for
languages such as javascript/python and ruby and most important XML. I
feel that this will be required to get the performance needed for a
xml desktop.


Thank you for WebKit

Michael Emmel