As some of you may have noticed, there is now a PLATFORM(CHROMIUM) define that is being used in WebKit. I thought it might be helpful to describe what it is and explain why it exists.
PLATFORM(CHROMIUM) corresponds to the WebKit porting layer implementation used by the Chromium (aka Google Chrome) browser. While Chromium runs on Windows (and soon Mac and Linux), it turns out that it puts an interesting set of constraints on WebKit that cause the existing WebKit ports to be mostly unusable by Chromium. The main constraint is the Chromium sandbox, in which WebKit is run. This technology does things like block access to the filesystem, registry, sockets, and desktop (aka GUI system). This latter constraint is the most impactful one since it means that HWNDs associated with the desktop cannot be accessed or modified by the sandbox. This ends up having huge implications for not only rendering but also popup menus, context menus, drag-n-drop, clipboard operations, theming, cursors, and event processing. All of those things need to be handled in the main process that does have access to the desktop. So, while we started out with PLATFORM(WIN) as the basis of our port, we ended up touching and heavily modifying just about every file in the WebCore/platform/win/ directory. In the process, we also built-up essentially a toolkit within the Chromium source tree on which our port was then based. In hindsight, it is obvious to me that what we were building was really just a new WebKit port, and so we moved all of our work to the PLATFORM(CHROMIUM) define. We are in the process of upstreaming that port, starting with a sprinkling of PLATFORM(CHROMIUM) defines in WebCore that eliminates modifications to shared files. In the coming months, we plan to upstream the rest of our port. We haven't been able to do so yet because we are trying to move ourselves to tip-of-tree WebKit first. In the long run, I suspect that there will be some commonalities between PLATFORM(CHROMIUM) and the other ports that we can work to eliminate. I look forward to getting to that point. For now, the plan is to upstream PLATFORM(CHROMIUM) as a complete entity. Other defines: The Chromium build of WebKit also includes some other changes to WebKit beyond just a new porting layer. I thought I should talk about those too. USE(V8) This corresponds obviously to the V8 <http://code.google.com/p/v8/>JavaScript engine used by Chromium. In our tree, we have a liberal sprinkling of these defines. Instead of upstreaming those wholesale, we are working to build thin abstractions in WebCore that hide the underlying JSC and V8 data types and method calls. In some cases, this ends up simplifying some existing JSC-using code, and I hope that this will be well received. USE(SKIA) Chromium uses the Skia graphics engine<http://blog.chromium.org/2008/10/graphics-in-google-chrome.html>to perform 2D rendering on Windows and Linux. (On Mac, Chromium is using CG.) Our intent is to upstream a platform/graphics layer built on top of Skia that will be generally useful to ports. For those who are unaware of Skia, it is the graphics engine developed for the Android mobile OS. USE(GOOGLEURL) As has been discussed at length in another thread, Chromium also uses the GoogleURL <http://code.google.com/p/google-url/> library for URL parsing and canonicalization. We implemented the KURL interface on top of GoogleURL so that we could have consistent URL parsing and canonicalization throughout the entire product. This was done to ensure correctness, which helps avoid/eliminate classical security bugs, and help achieve good performance when converting between KURL and GURL. To be clear: Our intent is to minimize the occurrence of any of these new #ifdefs in the shared, cross-platform WebKit code, so that we minimize any maintenance burden related to these new defines. I'm very excited to finally have the chance to share our work with the WebKit community. I really look forward to having Chromium live at tip-of-tree WebKit, so that we can work alongside you on more interesting improvements and innovations to the core rendering engine. Regards, -Darin
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
