Hi Morgan,
On 12/6/06, Morgan L <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
To: [email protected]
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 <[EMAIL PROTECTED]> 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
> [email protected]
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
_______________________________________________
webkit-dev mailing list
[email protected]
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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
