-
Notifications
You must be signed in to change notification settings - Fork 8
Frequently Asked Questions
No, but it will soon be possible to do so from the WebKit nightly binary builds. This is tracked here: https://bugs.webkit.org/show_bug.cgi?id=130700.
In practice, usually not.
Because Timelapse records inputs to a program instead of the actual instructions executed, relatively little time is spent capturing and saving data during recording. The amount of data captured scales with user input, not CPU time. Even for applications with high rates of user input (such as video games), Timelapse doesn't introduce a noticeable decrease in performance.
On program replay, Timelapse can replay the execution much faster than the speed at which it was recorded. This is because page resources are loaded from memory instead of over the netwrok, "user delay" can be elided, and the results of some platform functions can be memoized instead of re-executed.
All HTTP requests and responses are captured, so the recording's size is the sum of all resources requested during the execution, plus the size of each nondeterministic input. Most such inputs are really small and highly compressible. The total size of the recording will scale with the number of program inputs, such as network requests, user mouse/key input, and timer callbacks.
In our preliminary performance evaluation, applications with high rates of user input (such as timer-based video games) generate at most 250KB/minute of input, and this can be compressed to under 50KB for storing or transmitting recordings. These numbers do not include network traffic/page resources, which can also be compressed (and generally dominate the size of recordings).
On replay, network requests are intercepted by an in-browser network simulator.
External servers will not re-receive network requests during replay. A network-level record/replay simulator captures all HTTP headers and traffic when recording, and only allows the same requests to occur on replay. From the web page's point of view, the external server appears to behave the same on recording and replay, though on replay the network traffic actually originates from the recording.
Right now, no. It is actively developed for the Mac port (i.e., OS X desktop, not iOS). We (at the University of Washington) do not have the engineering time available to add support for other WebKit ports. Other platforms will definitely not work out of the box. That said, the implementation approach for Timelapse is platform-independent and does not overly rely on platform-specific APIs. See the next question for details.
It's not a trivial amount of work, but not particularly challenging either.
There are several platform-specific parts of code to implement, in order of increasing effort:
Each platform has its own build system and/or build settings. Web replay is behind the ENABLE_WEB_REPLAY flag, which toggles compilation of the replay infrastructure. So, you will need to ensure that feature can be toggled on, and the build system is aware of feature-specific files. For example, most files in Source/WebCore/replay/ are not added to CMakeLists.txt. See Adding Files To WebKit for more details.
Each embedding application/library uses a different subset of the WebKit/WebKit2 embedding APIs. In some cases, embedders may use API calls that have not yet been piped through the user input bridge between WebCore and WebKit2. Fixing this could be as simple as calling a different method, or as hard as adding/controlling an entirely new source of nondeterminism.
Each platform introduces its own sources of nondeterminism, which must be controlled for record/replay to work correctly. For example, the Timelapse code specific to the Mac port exists to memoize accesses to the system-shared cookie jar.
The infrastructure for recording and replaying is a part of the WebKit engine, which is mostly written in C++. The developer tool UI is written using HTML, CSS, and JavaScript. Accompanying scripts and tools are predominantly written in Bash and JavaScript.
For replay infrastructure, we write regression tests that starts up a test page, records some interaction with it, and compares replay output to captured output. WebKit's test harness provides access to test both the models and controllers Web Inspector UI, and the C++ backend to which it communicates. See the WebKit wiki page for more details.
Many of the mechanisms would be the same, but it would be several months' work to port the replay backend.
It's possible, but not straightforward. It would require substantial redesign because the architecture is different.
Development of core replay infrastructure happens directly on WebKit trunk. See http://webkit.org/ for guidelines on contributing to that project. Be sure to file it as a Web Inspector Bug.
More experimental features are developed on this Github project, which hosts research offshoots of the main replay infrastructure. Please open an issue or pull request if you have something to contribute. Definitely get in touch before doing significant work, as we make no guarantees about what happens in the Github repository.