[webkit-dev] WebCore/platform directory

[Sebastien Roret]

Hi Morgan,

On 12/6/06, Morgan L <morganl.webkit at yahoo.com> wrote:
>
> 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.
>

Thanks for  your feedback.
I agree with you, the needed abstraction can also be achieved with
d-pointers (Cheshire Cat design pattern). But the interface classes seemed
simpler and clearer to us (and decoupling easier), though we must provide an
instanciation mechanism (like a factory), manage object lifetime, and
abstract classes can't be used in standard template library containers (only
pointers). This is not really a problem, and factory even allow us to
disable some functionality by returning null for example.


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'm not aware of any significant performance overhead between the d-pointer
/ interface class policy.
If you have any pointer about that, I'd be glad to read it.

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

Perhaps by the means of interface classes ?  ;)

Seb

-- 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
>
>
> ------------------------------
> Have a burning question? Go to Yahoo! Answers<http://answers.yahoo.com/;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx>and get answers from real people who know.
>



-- 
Sébastien Roret
Origyn Web Browser for Embedded Systems Team
Senior Software Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20061207/53409e8e/attachment.html