Alexandru Chiculita, Computer Scientist, WebKit team
The JavaScript engine used in Safari
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
Byte Compiler
using internal bytecode format
Assembler
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
Interpretor
runs the generated bytecode
Regexp engine
with JIT support
Garbage collector
mark-and-sweep
Runtime
all the JS global objects (Date, String, Number, etc.)
Debugger, Profiler
Resource loaders
HTML & XML parsers, DOM
SVG & SMIL
CSS
Parser, Selectors, Animations
Rendering and layout
Bindings generator
IDL files: JSC, V8, ObjC
HTML5 features
audio, video, canvas, WebGL, notifications
WebInspector
Platform integration
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
Managed access to OpenGL ES APIs from JavaScript
Slide /
#