See the webkit.js Google Group for Discussions & Questions
- Develop frameworks for image/webpage capturing and automated web testing (similar to PhantomJS).
- Develop a framework for prototyping CSS filters, HTML elements and attributes.
Fixing canvas size bitblt issues; canvas width and height can become inaccurate due to hi-dpi rendering. Alpha channels are being flattened for unknown reasons, in addition gradients and animations in css are not rendering. Inline SVG seg-faults. Most likely due to threading issue. Certain CSS3 key-frame animations cause either a segfault or jump to the last frame, uncertain but it seems to be an issue with ChromeClient and TextureMapperGL.
- Mouse and keyboard (and other) events
- IN-PROGRESS: Resource loader has yet to be implemented, callback for browser (and eventually node)
- (Fixed, see emscripten post, waiting for it to land)
Support for WebGL within webworkers via proxy (emscripten is currently working on this)
- Enhancing the API. Adding mouse event callbacks, scrolling, keyboard callbacks, and snapshot to it. Until there's a stable (well tested) API this will remain as an experiment.
The entire HTML5, CSS3 and SVG rendering is supported; the following features are not supported and probably will never be.
- Encrypted Media
- Quota's and File System (Browser Only)
- Web Timing (Implemented, but inaccurate due to limitations in JS spec).
- Native OS Widgets (although "webkit" standard widgets, or any css styled widgets, e.g., input fields are supported).
Fonts are rendered via freetype2, fontconfig and cairo for consistent font rendering across all platforms. Native video and audio decoding is supported but not included in the regular build. Eventually i'll post instructions on compiling in native video/audio support.
webkit.js can be built on linux, osx, or windows.
- Xcode (OSX only)
- Visual Studio (Windows only)
- Cygwin (Windows only)
- Command Line Utilities for Xcode, with
$ xcode-select --install(Mac OS X only)
- At least 16GB of free space (seriously)
- At least 4GB of RAM
Building webkit.js step-by-step
- Clone the repo to your local drive.
git clone https://github.com/trevorlinton/webkit.js webkitjs ; cd webkitjs
- Run the setup script to grab all of the dependencies and tools.
- Run the configuration script to generate build and project files.
- Then to build; run this (generates the actual js file):
- OR if you want a debug version run this:
Running in the Browser
See demo.html and webkit.js in the "bin" folder, runs best in Firefox (Chrome/Safari seem to have large long hiccups and freezes due to garbage collection).
Getting around the code
/deps/WebKit/This is a modified version of Apple's official repo.
/deps/WebKit/Source/WebCoreThis is where 90% of the work is done.
/deps/WebKit/Source/WebCore/bindings/scriptsThis is an important folder where WebKit autogenerates bindings
/deps/WebKit/Source/WTF/is a cross-platform library for common tasks such as HashMaps, etc.
/deps/WebKit/Source/WTF/PlatformJS.hthese are C++ pre-process settings for PLATFORM(JS)
/features.gypiYou can turn various features in WebCore on and off here
/common.gypiYou can change various compiler settings, system paths, etc.
/webkit.gypThis contains the build arch and is the first file used when generating project files with gyp.
/sources.gypiThis file contains the list of all of the sources to compile.
/derived.gypiThis file is auto-generated by make-source-files.sh in the tools directory, it hunts down any changes vs. what's in derived.gypi currently and adds it in. This is convenient only when you've done a pull from WebKit and need to make sure you've properly added/removed files based on what's happened upstream.
/config.shThis autogenerates the project files, it also tries to find em++/emcc and all of your tools, if config files, check the file to make sure its finding emscripten and clang.
/binThis contains the latest builds for debug and release modes. Note that the debug builds are compressed for the sake of github.
/src/WebView.cppThis is the main 'essential' class and loading class for everything.
/src/Main.cppThis is a proxy from C++ to C, so we can use the emscripten exported symbols features.
It's important to know
- The code within the WebKit folder is pulled from upstream, be careful not to move any files, remove any files or heavily refactor any source file as it will cause headaches when merging.
- Enabling/disabling settings within the
features.gypiwill have a lot of consequences, most of the disabled features are disabled because there's no possible work around for including the platform specific or network layer code (bindings to forward this to the native browser/nodejs module will need to be built). In addition, if features.gypi is modified that you update featurs.make within the tools folder.
- A good amount of the bindings and code within the WebCore are auto generated from scripts, be careful when you have build errors to make sure you're not modifying a "Derived Sources" file, otherwise you'll find your changes will be just over-written the next time this script runs.
- Do not modify code within
src/WebCoreDerived, it's autogenerated and will most likely be overwritten if the derived sources needs to rebuild.
- Becareful adding files/changing settings in your native IDE/toolchain, these settings are intially set in
common.gypi(and related gypi/gyp files). While not all settings will be overwritten with a new config, there's a chance some of your settings may need to be added to these files.
A build toolchain similar to GYP/gconfig. QtWebkit has one already, possibly re-map that.
Create "Debug" and "Release" modes that allow for easier debugging. In addition creating anything that helps debug and spot problems easier.
Integration of WTF library into WebCore
- Bad Idea -
Start smaller with GYP and only develop one pass layout system from CSS/HTML/DOM code with minimal features and build up.
- Bad Idea -
Take each file one by one in ./webkitjs/debug/ and port?...
Dependency and/or symbol graph that rebuilds automatically after a compile (expressed as a HTML doc?) The core reason for this is to visualize dependencies between classes, unresolved symbols still to be developed, and spot key integration points. This can be done by regex over the existing ./webkitjs/debug for symbols and building a D3 graph to show the symbols dependency possibly? Is there already key software that does this? Can emscripten/llvm spit this out?
Identify what key import symbols may require significant retooling.
Integrate libxml.js (rather than depending on browser pass through decoding to a buffer)
Integrate libxslt.js (currently unsupported)
Integrate libpng.js (rather than depending on browser pass through decoding to a buffer)
Integrate libjpeg-turbo.js/libjpeg.js (rather than depending on browser pass through decoding to a buffer)
Integrate zlib (rather than depending on browser pass through decoding to a buffer)
Integrate both node and web browser environments for testing demo of basic HTML
Integrate support for font resource loading and virtual file system for fontconfig
- Bad Idea -
Explore best methods for creating demo's and painting within WebKitJS.cpp to the host context.
Experiment with emscripten outlining, lto, and optimization techniques to prevent variable/heap/stack limitations and reduce code size.
Investigate if SKIA might provide better rendering -- no, skia does not support accelerated back-tile compositing needed by WebKit
Support for hidpi rendering on retina displays, support for device scale factors and clean font rendering
- In Progress Create examples, demos and how-to guides (documentation, etc).
- DONE Create hooks into webkit layout tests to ensure functionality.
- DONE Fix all layout tests for still-frame and render tree unit tests.
- DONE Fix timing animation (CSS3) bug
- In Progress Removal of "oddity" code (e.g., no mans land code, existing dead code, platform specific code) and optimization of file size and runtime
- In Progress Benchmark harnass between different browsers and webkit.js
- Everything else that's actually fun and note worthy (listed above in Goals).
BSD License. Use of this source code is governed by a BSD-style license that can be found in the LICENSE files contained in the root of the respective source code.
© True Interactions 2014 (www.trueinteractions.com)