[webkit-dev] WebCore/platform directory

Morgan L morganl.webkit at yahoo.com
Thu Dec 7 17:26:41 PST 2006 

Virtual functions are more expensive than the "Cheshire Cat" pattern because they add code bloat to each call-site.  To call a virtual function the compiler must generate extra code to dereference the object's vtable, whereas with a d-pointer approach that cost exists only once at the site of the implementation.  Moreover, the d-pointer approach allows cross-platform code to be more easily shared between the ports.  The approach breaks down, however, when header files are heavily #ifdef'd as they are in much of WebCore today.  It seems to me that there is a happy middle ground to be had :-)

-- morgan

----- Original Message ----
From: Sebastien Roret <sroret at gm.sand-labs.com>
To: Morgan L <morganl.webkit at yahoo.com>; webkit-dev at lists.webkit.org
Sent: Thursday, December 7, 2006 2:58:57 AM
Subject: Re: [webkit-dev] WebCore/platform directory

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 and get answers from real people who know.





-- 
Sébastien Roret
Origyn Web Browser for Embedded Systems Team
Senior Software Engineer






 
____________________________________________________________________________________
Have a burning question?  
Go to www.Answers.yahoo.com and get answers from real people who know.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20061207/2ee17168/attachment.html

More information about the webkit-dev mailing list