[webkit-dev] WebCore/platform directory

[Morgan L]

Hi, I don't speak for the WebKit developers, but I'm also interested in WebKit porting.  One bit of feedback that you might find useful:  I don't think it is necessary for all of the platform classes to be defined with virtual functions.  That would only be necessary if there could be multiple implementations of those platform "interfaces" within the same executable / shared-library.  For most things that is not the case, and sufficient abstraction can be achieved via the "d" pointer w/ a type that is defined by the port implementation.

In the shared, platform header file:

class PlatformFoo {
 public:
  void doStuff();
  ...
 private:
  struct PlatformFooPrivate *d;
};
 
In the platform specific implementation file:

struct PlatformFooPrivate {
  ...
};
void PlatformFoo::doStuff() {
  // use "d"
}

The advantage to this approach is that calling doStuff() remains cheap (no virtual function overhead), and since there are a lot of platform level methods, making them all virtual could really add up to measurable performance overhead.  On small devices with limited CPU cache, this matters even more.

I think it would be helpful if the WebKit platform-level headers were cleansed of platform specific #ifdef's as much as possible (entirely!) to help make the porting layer more contained and well-defined.


-- morgan


----- Original Message ----
From: Sebastien Roret <sroret at gm.sand-labs.com>
To: webkit-dev at lists.webkit.org
Sent: Wednesday, December 6, 2006 9:47:11 AM
Subject: Re: [webkit-dev] WebCore/platform directory

I'd like to share with you some ideas we had about the platform/ directory.
First, our aim is to use WebKit on embedded  platforms. We did a sample Linux implementation based on SDL.


It was easy to see what we needed
to implement thanks to the platform/ dir. But hopefully we will have to
do many ports, and some parts have to be reusable as is.



On way
to ease those ports was to abstract all headers in platform/ (only pure
virtual methods in classes). Thus, headers in platform would be truly platform-independent. Moreover we avoid the need of adding a #ifdef for each platform. The platform/ dir can then be considered as a Browser Abstraction Layer.




We started from Mike Emmel's GDK port, we cut out platform into several subdirs placed in BAL/Implementation :
Events, abstracted events and event loop ;


Fonts ;
Graphics, abstracted GraphicsContext, and files as in platform/graphics/ ;

ImageDecoders ;
Network ;
Types, various cross-platform types ;
Widgets.And in BAL/Interfaces, all abstract headers that should be implemented in BAL/Implementation.

We also thought of an abstraction for :
Internationalization (ICU library);
Posix (libm, memory manager for now);
XML (libxml and libxslt).
This way, the BAL is 
independent of WebCore and can be compiled aside. Unit tests have been written and are reusable for each platform.


What do you think about this choice for platform/ ?
We plan to publish this sample implementation and the abstraction layers impacting changes as soon as 
we've reached a reasonably stable and mature level.



Sebastien.


On 12/5/06, Darin Adler <darin at apple.com> wrote:
Recently, we discussed the platform directory a bit in a bug <http://
bugs.webkit.org/show_bug.cgi?id=11596>.

I thought I'd say a few things on this point to the entire list.


The "platform" directory is where we have the platform that the rest
of WebCore is built on top of. The primary focus is platform-
independent wrappers for platform specific services, like events,

graphics systems, as well as some basic data structures.

The platform independent interfaces and implementation are at the top
level, and platform-specific implementations go into directories
named with the nickname for each platform (
e.g. "mac" for Macintosh,
"qt" for Qt, "win" for Windows). Since most headers are shared, some
platform-specific code is in the headers guarded by appropriate #if
statements.


We also expect to have platform-specific implementations in some
other places in the source tree. What goes into the platform
directory is a platform abstraction that the rest of the library is
built on. But in some cases, you can't build the platform specifics

into a platform abstraction -- you need platform specifics in the
higher level code.

At the moment, a couple of directories that are have this kind of
platform-specific code are page and loader. (Much of the code

currently in bridge/mac belongs in page/mac.) While we'd like to keep
from doing this all over the code, we will need platform specifics
outside the platform directory when they can't easily be abstracted
into a generic cross-platform concept.


I see signs that people are misunderstanding this approach a bit. For
example, FrameQt and PageQt absolutely do not belong in platform/qt.
They should be in page/qt instead.

I'm sorry that this wasn't explained clearly enough in the past.


     -- Darin
_______________________________________________
webkit-dev mailing list
webkit-dev at lists.webkit.org

http://lists.webkit.org/mailman/listinfo/webkit-dev





_______________________________________________
webkit-dev mailing list
webkit-dev at lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev







 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20061206/2a2ab8de/attachment.html