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
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
