[webkit-dev] YAPP Yet another porting project
mjs at apple.com
Thu Feb 16 02:24:46 PST 2006
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
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
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
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
> Our long term plans are pretty big.
> We want to develop a XML centric application environment on top of
> 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.
> 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,
> 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
> 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.
More information about the webkit-dev