Alexandru Chiculita, Computer Scientist, WebKit team
A bunch of C++ templates that tries to replace STL
The rendering engine. Most of the code is here.
Old platform integration code.
Used by Chromium which has its own cross-process code.
New platform integration code used in Safari since version 5.
Based on a cross process architecture.
Attention! This is not used by Chromium.
Used in Safari
JavaSript Parser, JSON Parser
using internal bytecode format
uses code patching at runtime -> it needs writeable code memory
Data flow graph
new initiative to optimize the generated code based on compile time speculations
runs the generated bytecode
with JIT support
all the JS global objects (Date, String, Number, etc.)
HTML & XML parsers, DOM
SVG & SMIL
Parser, Selectors, Animations
Rendering and layout
IDL files: JSC, V8, ObjC
audio, video, canvas, WebGL, notifications
Graphics, Fonts, Sound, Video
The only task for these projects is to expose platform functionality to WebCore layer.
The port maintainers implement and extend this code.
NSWebView from Mac
Android's Java WebView API
Processing is postponed until the last moment
How much memory is your patch using?
How is it impacting performance?
Is it useful for all the existing sites?
For example in Flex, the app developer makes sure
the application code doesn't break the layout
It may happen as a side effect of parsing
It may be needed to maintain it forever
Activated using -webkit-transform and CSS animations
Implemented in RenderLayer
Drawing pipeline is platform dependent
No 2D GPU acceleration in WebKit
CoreGraphics on Lion and Skia
have GPU accelerated 2D drawing