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