[webkit-dev] YAPP Yet another porting project

[Maciej Stachowiak]

On Feb 12, 2006, at 8:43 AM, Mike Emmel wrote:

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

That sounds pretty cool! We would love to see the Gtk port updated  
and merged back into the mainline sources, and working on top of  
directfb would be a nice bonus.

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

For the first version we will likely start with the win32 native  
services (UniScribe and such) for text rendering.

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

I think it would be just fine to convert to floats before calling  
Cairo. This happens with the CoreGraphics APIs on Mac OS X and it's  
not been a hindrance to our performance. However, we will be working  
on a cross-platform abstraction layer for graphics which will have  
Cairo and CG as two of the available back ends.

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

Stable in what sense? I believe it is reasonably stable right now in  
that it doesn't crash too much or have too many regressions. However,  
the source tree is changing rapidly

However, it's pretty likely that the sources will always be changing  
rapidly.

Right now we are reworking our approach to portability. Dave Hyatt  
has mentioned it a couple of times now, but I'll say it again.

Instead of the kwq model where we emulate Qt classes, we will have a  
platform neutral abstraction layer in JavaScriptCore/kxmlcore (for  
low-level stuff that JSC might need too) and WebCore/platform (for  
higher-level things). These classes will be cross-platform as much as  
possible, but some will have platform-specific implementations. At  
the other end, we will have WebCore/bridge where platform-specific  
API bridging code will live. This will allow different platforms to  
each have a different convenient, native-feeling API to the same  
underlying engine.

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

Our own plans are to render the widgets almost entirely using the  
layout engine, including even text input controls. WebKit supports  
HTML editing so that's definitely feasible. We use a small bit of per- 
platform code to draw the right native looking background.

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

I would not recommend running these components as a service  
communicating via shared memory. This will make apps really slow,  
from the locking overhead on shared data structures and message  
passing / synchronization overhead. It's not really clear what the  
win would be, either. Better for each app to just link the full library.

Also, it's pretty hard to break out the DOM from CSS, rendering,  
parsing, etc.

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

It's pretty difficult to design an interface such that you could plug  
in a language-specific DOM and rendering engine, for performance it  
is best to have HTML+SVG+CSS rendering all built into the core engine.

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

I'm not sure how compiling XML would work - it's not a programming  
language. A pre-parsed binary format can help loading but a butecode  
format doesn't really apply.

But your plans sound interesting and ambitious.

Regards,
Maciej